1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/org/cleanup-message.txt	Tue Oct 25 13:17:37 2011 -0700
     1.3 @@ -0,0 +1,100 @@
     1.4 +My name is Robert McIntyre. I am seeking help packaging some changes
     1.5 +I've made to open-al.
     1.6 +
     1.7 +* tl;dr how do I distribute changes to open-al which involve adding a
     1.8 +  new device?
     1.9 +
    1.10 +* Background / Motivation
    1.11 +
    1.12 +I'm working on an AI simulation involving multiple listeners, where
    1.13 +each listener is a separate AI entity.  Since each AI entity can move
    1.14 +independently, I needed to add multiple listener functionality to
    1.15 +open-al. Furthermore, my entire simulation allows time to dilate
    1.16 +depending on how hard the entities are collectively "thinking," so
    1.17 +that the entities can keep up with the simulation.  Therefore, I
    1.18 +needed to have a system that renders sound on-demand instead of trying
    1.19 +to render in real time as open-al does. 
    1.20 +
    1.21 +I don't need any of the more advanced effects, just 3D positioning,
    1.22 +and I'm only using open-al from jMonkeyEngine3 that uses the LWJGL
    1.23 +bindings that importantly only allow access to one and only one
    1.24 +context.
    1.25 +
    1.26 +Under these constraints, I made a new device which renders sound in
    1.27 +small, user-defined increments.  It must be explicitly told to render
    1.28 +sound or it won't do anything.  It maintains a separate "auxiliary
    1.29 +context" for every additional listener, and syncs the sources from the
    1.30 +LWJGL context whenever it is about to render samples.  I've tested it
    1.31 +and it works quite well for my purposes.  So far, I've gotten 1,000
    1.32 +separate listeners to work in a single simulation easily.
    1.33 +
    1.34 +The code is here: 
    1.35 +http://aurellem.localhost/audio-send/html/send.html
    1.36 +No criticism is too harsh! 
    1.37 +
    1.38 +Note that the java JNI bindings that are part of the device code right
    1.39 +now would be moved to a separate file the the same way that LWJGL does
    1.40 +it. I left them there for now to show how the device might be used.
    1.41 +
    1.42 +Although I made this for my own AI work, it's ideal for recording
    1.43 +perfect audio from a video game to create trailers/demos, since the
    1.44 +computer doesn't have to try to record the sound in real time.  This
    1.45 +device could be used to record audio in any system that wraps open-al
    1.46 +and only exposes one context, which is what many wrappers do.
    1.47 +
    1.48 +
    1.49 +* Actual Question
    1.50 +
    1.51 +My question is about packaging --- how do you recommend I distribute
    1.52 +my new device?  I got it to work by just grafting it on the open-al's
    1.53 +primitive object system, but this requires quite a few changes to main
    1.54 +open-al source files, and as far as I can tell requires me to
    1.55 +recompile open-al against my new device. 
    1.56 +
    1.57 +I also don't want the user to be able to hide my devices presence
    1.58 +using their ~/.alsoftrc file, since that gets in the way of easy
    1.59 +recording when the system is wrapped several layers deep, and they've
    1.60 +already implicitly requested my device anyway by using my code in the
    1.61 +first place.
    1.62 +
    1.63 +The options I have thought of so far are:
    1.64 +
    1.65 +1.) Create my own C-artifact, compiled against open-al, which somehow
    1.66 +"hooks in" my device to open-al and forces open-al to use it to the
    1.67 +exclusion of all other devices.  This new artifact would have bindings
    1.68 +for java, etc.  I don't know how to do this, since there doesn't seem
    1.69 +to be any way to access the list of devices in Alc/ALc.c for example.
    1.70 +In order to add a new device to open-al I had to modify 5 separate
    1.71 +files, documented here:
    1.72 +
    1.73 +http://aurellem.localhost/audio-send/html/add-new-device.html
    1.74 +
    1.75 +and there doesn't seem to be a way to get the same effect
    1.76 +programmatically.
    1.77 +
    1.78 +2.) Strip down open-al to a minimal version that only has my device
    1.79 +and deal with selecting the right open-al library at a higher level,
    1.80 +depending on whether the user wants to record sound or actually hear
    1.81 +it.  I don't like this because I can't easily benefit from
    1.82 +improvements in the main open-al distribution. It also would involve
    1.83 +more significant modification to jMonkeyEngine3's logic which selects
    1.84 +the appropriate C-artifact at runtime.
    1.85 +
    1.86 +3.) Get this new device added to open-al, and provide a java wrapper
    1.87 +for it in a separate artifact. Problem here is that this device does
    1.88 +not have the same semantics as the other devices --- it must be told
    1.89 +to render sound, doesn't support multiple user-created contexts, and
    1.90 +it exposes extra functions for retrieving the rendered sounds. It also
    1.91 +might be too "niche" for open-al proper.
    1.92 +
    1.93 +4.) Maybe abandon the device metaphor and use something better suited
    1.94 +to my problem that /can/ be done as in (1)?
    1.95 +
    1.96 +
    1.97 +I'm sure someone here knows enough about open-al's devices to give me
    1.98 +a better solution than these 4!  All help would be most appreciated.
    1.99 +
   1.100 +sincerely,
   1.101 +--Robert McIntyre
   1.102 +
   1.103 +