[Audio-engine-dev] Gervill 0.2
Alexey.Menkov at Sun.COM
Fri Oct 12 11:25:24 PDT 2007
see my notes inline
Florian Bomers wrote:
>> As a 1st step I suggest to create such interface in com.sun.media.sound
>> package, and them move it to javax.sound.midi.
> I don't see an advantage for going in 2 steps, I'd prefer to put
> it in javax.sound.midi directly.
As you know I have to get CCC approval for API changes and getting of
the approval may take a long time (and the approval is not required to
make any changes in internal com.sun.media.sound package). So the
interface may be created in com.sun.media.sound and when approved just
be moved into javax.media.sound.midi
But may be we don't need the intermediate stage due SoftSynthesizer
project will survive as separate part before integration into JDK, so we
will have enough time to get all approvals.
>> So we need to determine which methods should be included in the extended
>> As for me the main method is setMixer(javax.sound.sampled.Mixer) (I'm
>> not sure about SourceDataLine - other implementations can require
>> several lines).
> yes, see my proposal for that.
>> Ability to specify preferred AudioFormat, Latency & Polyphony is a good
>> feature, but most likely it should be optional.
> I'd suggest to add "properties" for advanced functionality,
> similar to AudioFormat's properties, except that they can be set
> after instanciation.
I thought about something like this, the main difficulty I see is how to
make restrictions (available values) for the specific properties like
"resamplerType" (the interface will be public, so other interface
implementations should have ability to add its own supported
"resamplerType" values as well as its own properties).
Do you have an idea how it can look?
>> BTW do you think selecting from several resamplers is useful feature?
> yes, very useful. E.g. for realtime playback, a linear
> interpolator will be enough (for the sake of compatiblity, CPU
> usage, etc.). But for a software that renders MIDI files to disk
> (e.g. by using the setOutputStream() method of my proposal),
> quality matters more than realtime performance.
Okay, I've got it.
Just one note - if some resampler is not fast enough for realtime
playback, it most likely produce bad results for software rendering
(sequencer anyway works in realtime and will not wait while synthesizer
complete processing of previous messages before sending new one).
>> If somebody wants to capture synthesizer outputs, he will implement
>> simplest Mixer and set it as output mixer for the synthesizer.
> I think a way of directly grabbing the synth output by way of
> OutputStream (or AudioInputStream, maybe better) will be more
> versatile and more Java like.
With such approach we also haven't to implement fully spec-compliant Mixer.
>> 3. Why the synth support only single receiver? (look at
>> com.sun.media.sound.AbstractMidiDevice for example of multi-recevers
> yes, should support multiple receivers.
>> 4. WaveFloatFileReader: it seems to me that the class is not used anywhere.
>> 5. LargeSoundbankReader: what use cases you see for it? (as far as I see
>> from the code, currently its feature is not used anywhere)
>> Karl Helgason wrote:
>>> I have updated the midi synthesizer:
>>> - Large format support.
>>> - Fix SoundFont modulator mapping.
>>> - Fix handling of unsigned 16 bit streams
>>> - Improved GUS patch support
>>> - Add support for ping-pong/bi-directional and reverse loops
>>> Karl Helgason
>>> audio-engine-dev mailing list
>>> audio-engine-dev at openjdk.java.net
>> audio-engine-dev mailing list
>> audio-engine-dev at openjdk.java.net
More information about the audio-engine-dev