Menu
▾
▴
linuxsampler-devel
|
From: <be...@ga...> - 2003-11-23 21:28:47
|
Christian made some fixes and has uploaded a new version: * rewrote sustain pedal handling: instead of just queuing the note-offs I added a sustain pointer for each midi key which starts to point to the first active voice on the respective key and increments to the next voice on the key when a note-off arrived, the release velocity value will immediately be stored in the respective voice object (this also fixes the segmentation fault issue when the sustain pool was full). Now the streams are deallocated properly. There is still a small bug that occurs when you max out polyphony. (probably in the disk stream, we will look into). Mark can you test if this version works for you ? cheers, Benno http://www.linuxsampler.org ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: Mark K. <mar...@co...> - 2003-11-23 22:56:40
|
On Sun, 2003-11-23 at 13:28, be...@ga... wrote: > Christian made some fixes and has uploaded a new version: > > * rewrote sustain pedal handling: instead of just queuing the note-offs I added > a sustain pointer for each midi key which starts to point to the first active > voice on the respective key and increments to the next voice on the key when a > note-off arrived, the release velocity value will immediately be stored in the > respective voice object (this also fixes the segmentation fault issue when the > sustain pool was full). > > Now the streams are deallocated properly. > There is still a small bug that occurs when you max out polyphony. > (probably in the disk stream, we will look into). > > Mark can you test if this version works for you ? > > cheers, > Benno > http://www.linuxsampler.org > Hi Benno, Was sitting here working on a problem for Jaroslav. This sounded like a nice break and a bit more fun. This version is much better behaved. It's no longer complaining about lack of memory when I load this big library, and so far I cannot crash it with the sustain pedal like before. Here's what it looks like when I start it. I've made no changes to the code, so you are handling the plughw thing yourself now in code. Thanks. Can I request that we maybe get a MIDI input hookup on the LS command line so that I can test LS without my having to use kaconnect? That would make things a bit easier. Wizard root # linuxsampler --numfragments 2 --gig /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ Grand\ Version\ 2.2.gig Initializing audio output...Warning: your soundcard doesn't support chosen hardware parameters; trying to compensate support lack with plughw...OK Loading gig file...OK Caching initial samples...OK Starting disk thread...OK Starting MIDI in thread...OK Starting audio thread...OK LinuxSampler initialization completed. Voices: 000 (Max: 000) Streams: 000 (Max: 000, Unused: 100) At this point I can play and I get voices OK. It seems that this version of the code maxes out at 64 voices, as far as I can tell, however the streams seem to be set up for 100. No free voice! No free voice! No free voice! No free voice!ax: 064) Streams: 062 (Max: 064, Unused: 038) No free voice! No free voice! No free voice! Note that the messages get overwritten in my xterm. What exactly is a 'stream'? So far the stream number always equals the voice number. Looking better all the time. Mark |
|
From: Mark K. <mar...@co...> - 2003-11-23 22:58:36
|
Oh, one strange thing. If I kill the xterm that LS is running in, using the window decoration 'X', LS is not killed and continues to work even with no terminal. It doesn't matter, really, but I thought I should report it. Cheers, Mark On Sun, 2003-11-23 at 14:56, Mark Knecht wrote: > On Sun, 2003-11-23 at 13:28, be...@ga... wrote: > > Christian made some fixes and has uploaded a new version: > > > > * rewrote sustain pedal handling: instead of just queuing the note-offs I added > > a sustain pointer for each midi key which starts to point to the first active > > voice on the respective key and increments to the next voice on the key when a > > note-off arrived, the release velocity value will immediately be stored in the > > respective voice object (this also fixes the segmentation fault issue when the > > sustain pool was full). > > > > Now the streams are deallocated properly. > > There is still a small bug that occurs when you max out polyphony. > > (probably in the disk stream, we will look into). > > > > Mark can you test if this version works for you ? > > > > cheers, > > Benno > > http://www.linuxsampler.org > > > > Hi Benno, > Was sitting here working on a problem for Jaroslav. This sounded like > a nice break and a bit more fun. > > This version is much better behaved. It's no longer complaining about > lack of memory when I load this big library, and so far I cannot crash > it with the sustain pedal like before. Here's what it looks like when I > start it. I've made no changes to the code, so you are handling the > plughw thing yourself now in code. Thanks. > > Can I request that we maybe get a MIDI input hookup on the LS command > line so that I can test LS without my having to use kaconnect? That > would make things a bit easier. > > Wizard root # linuxsampler --numfragments 2 --gig > /mnt/samples/Gigs/Pianos/Bardstown\ Audio/The\ Bosendorfer\ Imperial\ > Grand\ Version\ 2.2.gig > Initializing audio output...Warning: your soundcard doesn't support > chosen hardware parameters; trying to compensate support lack with > plughw...OK > Loading gig file...OK > Caching initial samples...OK > Starting disk thread...OK > Starting MIDI in thread...OK > Starting audio thread...OK > LinuxSampler initialization completed. > Voices: 000 (Max: 000) Streams: 000 (Max: 000, Unused: 100) > > At this point I can play and I get voices OK. It seems that this version > of the code maxes out at 64 voices, as far as I can tell, however the > streams seem to be set up for 100. > > No free voice! > No free voice! > No free voice! > No free voice!ax: 064) Streams: 062 (Max: 064, Unused: 038) > No free voice! > No free voice! > No free voice! > > Note that the messages get overwritten in my xterm. > > What exactly is a 'stream'? So far the stream number always equals the > voice number. > > Looking better all the time. > > Mark |
Thanks for helping keep SourceForge clean.
X