linuxsampler-devel — This list is for discussing LinuxSampler development issues and ideas

Re: [Linuxsampler-devel] ADSDR third try

[Vladimir S. <ha...@so...>]

Everybody,

Those two previous patches had a nasty bug, so here is another one. 
please disregard the other two.
Sorry for too many messages. It's weekend. you'll probably not hear from 
me on weekdays :)

Christian,
Does Release coefficient have to take sustain level into consideration?
It seems that it is not really necessary, but i'm not sure.

Regards,
Vladimir.

Re: [Linuxsampler-devel] Latest CVS commit

[Christian S. <chr...@ep...>]

Es geschah am Freitag, 16. Januar 2004 04:52 als Vladimir Senkov schrieb:
> I figured i better send a patch so it will be easier for folks to try it
> out:
>
> --- a/src/audiothread.cpp    Sun Jan 11 11:43:54 2004
> +++ b/src/audiothread.cpp    Thu Jan 15 22:44:50 2004
> @@ -319,11 +319,11 @@
>                          (*pVoicePtr)->Release();
>                          pVoicePtr = pVoicePtrNext;
>                      }
> +
> SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
> +                    pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
> +                    pMIDIKeyInfo[*key].Sustained   = false;
> +                    pMIDIKeyInfo[*key].hSustainPtr = NULL;
>                  }
> -
> SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
> -                pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
> -                pMIDIKeyInfo[*key].Sustained   = false;
> -                pMIDIKeyInfo[*key].hSustainPtr = NULL;
>              }
>              //SustainedKeyPool->empty();
>          }
>
> This should take care of that little problem with voices getting stuck . .
> . Christian, does this make sense?

Very good Vladimir! That was the problem; is now fixed in today's CVS version.

Cu
Christian

Re: [Linuxsampler-devel] ADSDR second try

[Vladimir S. <ha...@so...>]

Hi All,

Fixed a few issues:
- if sustainlevel == 0 set it to 1. some gigs have it at 0.
- some samples seem to use decay1 where they should perhaps have used 
decay2. so, release needs to be able to trigger during decay1 as well as 
decay2. For now this is what i did any objections?

Attempted to add post attack hold support, but i'm not sure i did it 
correctly. I only have one sample with post attack hold to play with.
I've used SamplePeriod (sample duration in nanoseconds) to calculate the 
hold time and i have doubts this because it's only 4 octets long. Seems 
a bit short for nanoseconds . . . If anyone could please point out what 
i missed there please do.
Patch is not incremental, so just disregard previous patch.

Regards,
Vladimir.

PS: still not finished work, not cleaned up, comments, etc so for 
testing only.

[Linuxsampler-devel] ADSDR first try

[Vladimir S. <ha...@so...>]

Hi All,

I've finally got around looking into enhancing EG to implement ADSDR 
(like Christian suggested).
The intent was, again, to just support features that .gig format 
supports, for now.
I have not implemented the preDecay1 hold yet, but it's almost there. I 
just need to learn a bit more about LS first to figure out how to learn 
if sample has been looped or not. Maybe i'll find that out tomorrow.

This is the very first try, code has not been cleaned up yet, some 
debugging might still be left there, some comments may be extra or 
missing :) very limited testing was done, with just a few samples.
This patch also includes the fix for "voices not going away" problem. 
I've also noticed that Level of preAttack was not computed correctly. 
I've changed all the Coeff values to be either positive or negative 
depending on the direction of the level, so that routine that uses Coeff 
to figure out the level can always add. I've moved most of that work 
into an inline function. It only looks like it has conditions they 
should be optimized out . . .

Anyway, patch is attached. Please give it a try and let me know how it 
looks.
I'll try to treat feedback on a timely manner so that it could be "ready 
for submit" sooner rather than later.

Regards,
Vladimir.

[Linuxsampler-devel] Re: LinuxSampler Control Protocol implementation (Rui Nuno Capela)

[<LV...@ao...>]

Just say Hi to all,

I'm new here, let me introduce myself:
My background is hardware ASIC (Custom IC programming) Engineer that what I'm 
doing for living, also, with little high level GUI programming for audio 
apps. 
About music, I was a Guitar and Piano player in nightclub about 5 years, 
currently own the small Digital and Analog Recording Studio since 1983...

I'm impressed on the LinuxSampler technology, not sure that I have much time, 
but I'm glad to be a Beta Tester?
Here is my first two-cent as follows:

Rui Nuno Capela wrote:
>>>>One of my objectives is that liblscp evolves as the implementation for a
linuxsampler API, while being a fair abstraction for the network and/or
ipc aspects of LSCP.<<<<

Wow, I'm not guru in programming, maybe that why this gives me more picture 
that how to do the API and client GUI whether Linux or wndows. Let say if this 
works, I might want to host LinuxSampler apps as VSTi in windows first of 
course, any ideas?

Best regards,
LongStudio


In a message dated 1/15/04 8:06:03 PM Pacific Standard Time, 
lin...@li... writes:


> LinuxSampler Control Protocol implementation (Rui Nuno Capela)
> 

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

I figured i better send a patch so it will be easier for folks to try it 
out:

--- a/src/audiothread.cpp    Sun Jan 11 11:43:54 2004
+++ b/src/audiothread.cpp    Thu Jan 15 22:44:50 2004
@@ -319,11 +319,11 @@
                         (*pVoicePtr)->Release();
                         pVoicePtr = pVoicePtrNext;
                     }
+                    
SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
+                    pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
+                    pMIDIKeyInfo[*key].Sustained   = false;
+                    pMIDIKeyInfo[*key].hSustainPtr = NULL;
                 }
-                
SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
-                pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
-                pMIDIKeyInfo[*key].Sustained   = false;
-                pMIDIKeyInfo[*key].hSustainPtr = NULL;
             }
             //SustainedKeyPool->empty();
         }

This should take care of that little problem with voices getting stuck . . .
Christian, does this make sense?

Regards,
Vladimir.

Vladimir Senkov wrote:

> Christian,
>
> I've looked a bit more into this problem.
> I think the root cause is in AudioThread::ProcessControlChange()
> In particular, hSustainPtr can be set for a key that is still pressed.
> In then becomes impossible for ProcessNoteOff() to do the right thing 
> . . .
>
> I tried to put these lines in AudioThread::ProcessControlChange():
>                
> SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
>                pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
>                pMIDIKeyInfo[*key].Sustained   = false;
>                pMIDIKeyInfo[*key].hSustainPtr = NULL;
> into the if statement just above:
> if (!pMIDIKeyInfo[*key].KeyPressed) { // release the voices on the 
> key, if the key is not pressed anymore
> so that it will not be done for keys that are still pressed.
> I gave it a very quick test and it looks like it's working correctly.
>
> Regards,
> Vladimir.
>
> PS: above is written at 2am in the morning under pressure to shut PC 
> down immediately therefore it can't be trusted :)
>
> Vladimir Senkov wrote:
>
>> Christian,
>>
>> Awesome!!!
>> I can't hear any noises at all with that free Steinway sample and 
>> default settings.
>>
>> But . . . I think a bug got introduced in the process.
>> Occasionally, some notes will not release completely. They'll get 
>> stuck in a state where i can still hear them but their volume is 
>> lower than usual.
>> If i play the same note again it goes away.
>> Kinda feels like a stuck key :) But it's not, because when i play the 
>> same thing with old ls (pre cvs update) i don't get into that state.
>>
>> After a while i found a way to reproduce: (other ways may exist also)
>> 1) play and hold note. (voices: 1)
>> 2) apply and hold sustain.
>> 3) release the note (keeps playing on sustain)
>> 4) play and hold the same note again (voices: 2)
>> 4) release sustain
>> 5) apply sustain (hold)
>> 6) release the note
>> 7) release sustain. (voices: 2!)
>> Voices will still be allocated and playing at this point!
>>
>> I'd love to implement PADSDR but i hope it's not very urgent as i 
>> need to do a bit of reading first.
>>
>> Regards,
>> Vladimir.
>>
>> Christian Schoenebeck wrote:
>>
>>> Changes:
>>>
>>>     -  There was still this annoying problem that some .gig 
>>> instruments were
>>>        detuned. I hope I have fixed this now. If you have still a 
>>> .gig that
>>>        sounds detuned, please let me know!
>>>
>>>     - As promised I finished an initial version of the amplitude 
>>> envelope
>>>        generator (EG1), so far only a simple ASR one. Extending it 
>>> to a PADSDR
>>>        one (as used in Gigasampler) is quite easy. If anybody likes 
>>> to do this
>>>        task, you just have to improve the EG_VCA class 
>>> (src/eg_vca.cpp). Vladimir
>>>        perhaps?
>>>        The EG has a minimum release time, in case the release time 
>>> given by the
>>>        gig file is 0s for example. Without this min. release time we 
>>> would again
>>>        have the click problem in case of zero release times when the 
>>> voice will
>>>        be released before it's sample end. This min. release time is 
>>> defined in
>>>        line 32 of src/eg_vca.h and there's another #define which 
>>> sets the bottom
>>>        value limit of the Exp curve, thus also defines the end of 
>>> the EG curve in
>>>        general. These two #define values still have to be adjusted 
>>> to good values
>>>
>>> CU
>>> Christian
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: Perforce Software.
>>> Perforce is the Fast Software Configuration Management System offering
>>> advanced branching capabilities and atomic changes on 50+ platforms.
>>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>>> _______________________________________________
>>> Linuxsampler-devel mailing list
>>> Lin...@li...
>>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>>
>>>  
>>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Perforce Software.
>> Perforce is the Fast Software Configuration Management System offering
>> advanced branching capabilities and atomic changes on 50+ platforms.
>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

[Linuxsampler-devel] liblscp: LinuxSampler Control Protocol implementation

[Rui N. C. <rn...@rn...>]

Hi all,

On the path for a GUI for linuxsampler, I've been taking some of my spare
time by writing an early implementation for the LSCP (the LinuxSampler
Control Protocol), as defined from the current available draft document.

My implementation, while still rather crude, is taking the form of a
programming library for plain conventional C, codenamed liblscp.

One of my objectives is that liblscp evolves as the implementation for a
linuxsampler API, while being a fair abstraction for the network and/or
ipc aspects of LSCP.

For the facts, liblscp is actually a wrapper for the LSCP specification,
taking all the TCP/UDP socket communication into it's main control, hiding
all or some of the protocol bureoucracy from the user and exposing a
simple and opaque C programming language interface, mainly by mapping
events to user function callback handlers.

The design of liblscp assumed that the programming interface provided is
useable and applicable either for server (linuxsampler itself) and/or
client (gui's) development.

Some design features (no rocket-sci here :)

* Multi-threaded server; but clients blocks for synchronous request calls.
* Multi-client; one server instance serves many clients, local and/or
remote.
* Server events broadcasted and delivered to client callbacks.
* Client requests processed on server supplied callback.

Please note that (as usual :) documentation is none at this stage but I'll
challenge you to look at the source code provided on the tarball below. A
barebones server and client test programs are included (lscp_server_test
and lscp_client_test).

As a quick reference for the server programming, one links to liblscp to
create a server instance, just like this:

    #include <lscp_server.h>

    lscp_server_t *server;

    server = lscp_server_create (server_port, server_callback,
server_data);

where server_port is the port number where the server will be
listening for connections; server_callback is the server supplied
callback function that will handle every client request; server_data is
any reference to data that will be fed into server_callback without
modification.

The server callback function must have the following prototype:

    lscp_status_t server_callback ( lscp_connect_t *conn, const char
*request, int reqlen, void *server_data );

where conn is just a client connection handle, that shall be used for the
server responses; the request text which has a length of reqlen bytes;
server_data is the same value given on lscp_server_create.

While handling each request the server must cook it's response and
eventually issue the following:

    lscp_server_result (conn, result, reslen);

where conn is the client handle, and result is a pointer to the server
response literal text of reslen bytes. Of course the response shall obey
to the protocol specification.

The server issues a broadcast to its subscribers by simply issuing:

    lscp_server_broadcast (server, buf, buflen);

which will trigger the client callback function, which will be fed with an
exact copy of buf/len; this is the intended way to deliver all
notifications to each subscribed client.

When its time to shutdown the server instance, just don't forget to call
the server destructor:

    lscp_server_destroy (server);

and we're done with the server.


Likewise, as for client programming, you create a client instance just
like that:

    #include <lscp_client.h>

    lscp_client_t *client;

    client = lscp_client_create (server_host, server_port,
client_callback, client_data);

where server_host is the hostname of the server we wish to connect, and
server_port is the respective port number; client_callback is the client
supplied callback function that will handle every server notification
event; client_data is intended for client context and will be fed to
client_callback without intervention.

The client may issue a request to server by use of:

    lscp_client_call (client, request, reqlen, &result, &reslen);

and the server response will be returned on result.

The client callback function prototype is very similar to the server one:

    lscp_status_t client_callback ( lscp_client_t *client, const char
*buf, int buflen, void *client_data );

where buf will be a pointer to the event text which is buflen bytes in
length; client_data is exactly the same value given on lscp_client_create
call.

This callback function is the place to handle all server notifications and
will be only called if the client is currently subscribed. No response
from the client is expected while processing an event within
client_callback.

A client subscribes to receive notifications by calling:

    lscp_client_subscribe (client);

after which it will start receiving events by means of the supplied
client_callback function. To unsubscribe and stop this deliverance:

    lscp_client_unsubscribe (client);

Finally, when a client is about to quit, the proper terminator is in order:

    lscp_client_destroy (client);


Nuff said. If you care or dare, you may check out the tarball attached to
this message (liblscp-0.0.4.tar.gz) or better yet, track the revolving
under:

    http://www.rncbc.org/ls/

Please note that the code is known to compile and run on linux AND on
win32 (!). On linux the main target is a shared library (liblscp.so) so
remember to set your LS_LIBRARY_PATH accordingly before running the test
programs.

A final disclaimer goes to the fact that I AM NOT a socket nor thread
programming guru, whatsoever. So fundamental mistakes may be lying around,
somewhere. Besides that ItJustWorks(tm:).

I'm eager to hear your feedback and comments. As usual, destructive
criticism will be sent to /dev/null ;)

Hope to be on the right track,
and towards linuxsampler integration.

Otherwise sorry for the bandwidth waste.

Cheers.
-- 
rncbc aka Rui Nuno Capela
rn...@rn...

Re: [Linuxsampler-devel] Giga VSTi

[Mattias H. <ma...@mu...>]

> An interesting thread I picked up at Northern Sounds leads to this site:
>
> http://www.fx-max.com

Yep, it's very interesting indeed, and the fact is that the Giga VSTi
adapter is working great in combination with FXTeleport as well :-) That man
has many cards up his sleeve, I can tell you that much!

/Mattias

[Linuxsampler-devel] A small LS ditty

[Mark K. <mar...@co...>]

Hi,
   I was listening to a semi-favorite art-rock band yesterday and ended
inspired to do something a little bit in their flavor last night. While
most of this GSt and other audio, I decided to use LS for one instrument
that didn't suffer too much for lack of LFOs, filters and other such
goodies yet to come. 

   Anyway, this is fairly unmixed and really just an idea I captured and
put together in about an hour, but I thought it would be fun for you all
to know that LS is getting to be quite usable when you're careful about
what you use it for.

   Kind feedback always welcomed. Flames to /dev/null. ;-)

http://marksmusic.myvnc.com/files/Glass1.mp3 

(5.2MB- 252Kb/S - 2:47)

Cheers,
Mark

[Linuxsampler-devel] Giga VSTi

[Mark K. <mar...@co...>]

An interesting thread I picked up at Northern Sounds leads to this site:

http://www.fx-max.com

Enjoy,
Mark

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Mon, 2004-01-12 at 06:56, David Olofson wrote:

> > I think this is related to GigaStudio's block chord note stealing.
> 
> Can you expand on that?
> 
> 
Dave,
   From GSt's help on the subject we're given just a few items to set up
- Master Attenuation
- Polyphony (up to the max you bought - 32, 96 or 160)
- Transition Voices

Transition Voices - Alter Transition Voices to steal notes from block
chords

Select the maximum number of voices that can be stolen from the decay
portion of a sound to support polyphony. While a higher setting provides
better block chord coverage, a lower setting increases overall
polyphony. If you hear pops while playing a high-polyphony passage, try
increasing this setting.

- Mark

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 17.36, Mark Knecht wrote:
> On Mon, 2004-01-12 at 08:13, David Olofson wrote:
> > > I think priorities could address my request. If the first X
> > > number of voices for any gig were high priority, then the
> > > piano's 50th note couldn't steal the violin's 1st note no
> > > matter how soft it was.
> >
> > That should work - and it has the advantage of not having to
> > figure out some "sensible" number of voices to reserve for each
> > gig, MIDI port, MIDI channel or whatever.
>
> And gives the user some control. If this could be a per 'port'
> setting in the LS GUI that would be pretty cool. (A 'port' in GSt
> is the place a Gig file sits and responds to  specific MIDI
> channel.) If I could say my piano will always get 10 voices, my
> violin will always get 3, etc., then I can tune that song by song
> as necessary.

Yeah. That's what the Roland JV-1080 and later synths do, BTW. Seems=20
to do the job, but most of the time I managed to get away without=20
using it. (64 voices and not too many sounds with extremely slow=20
releases. And some other h/w at times...)


[...]
> > Those 85-90% doesn't add *that* much to the experience, though!
> > ;-)
>
> Well, around library developers I think this statement verges on
> the religious, so I won't respond about their value beyond this
> sentence. ;-)

*hehe* Well, let's hope they don't take that more seriously than it=20
was intended! :-)


> That said, I think my point that by adding the release sample
> support sooner vs. later in LS would allow us to improve the disk
> handling of samples, better look at the overhead of the envelope
> generators (and all the other stuff like LFO's, looping, etc.) and
> thus better benchmark how well we're doing vs. the GSt solution. I
> can run GSt and LS on the same machine with the same sample drives
> and same sound card. It's about as apples to apples as we're going
> to get.

Yeah. The disk streaming and voice mixing (mostly a memory bandwidth=20
thing with simple interpolators, I think) is probably the most=20
critical part WRT performance. Next would be filters and stuff, but=20
control structure and most "little features" probably don't have that=20
a massive impact on performance.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Mon, 2004-01-12 at 08:13, David Olofson wrote:
> > I think priorities could address my request. If the first X number
> > of voices for any gig were high priority, then the piano's 50th
> > note couldn't steal the violin's 1st note no matter how soft it
> > was.
> 
> That should work - and it has the advantage of not having to figure 
> out some "sensible" number of voices to reserve for each gig, MIDI 
> port, MIDI channel or whatever.

And gives the user some control. If this could be a per 'port' setting
in the LS GUI that would be pretty cool. (A 'port' in GSt is the place a
Gig file sits and responds to  specific MIDI channel.) If I could say my
piano will always get 10 voices, my violin will always get 3, etc., then
I can tune that song by song as necessary.

> 
> > I think that doing very much benchmarking before release samples
> > are included is only going to lead to doing it again. In the piano
> > ogg above, what you hear from LS today is only 10-15% of what GSt
> > is doing with the same MIDI file.
> 
> Those 85-90% doesn't add *that* much to the experience, though! ;-)
> 
Well, around library developers I think this statement verges on the
religious, so I won't respond about their value beyond this sentence.
;-)

That said, I think my point that by adding the release sample support
sooner vs. later in LS would allow us to improve the disk handling of
samples, better look at the overhead of the envelope generators (and all
the other stuff like LFO's, looping, etc.) and thus better benchmark how
well we're doing vs. the GSt solution. I can run GSt and LS on the same
machine with the same sample drives and same sound card. It's about as
apples to apples as we're going to get.

I do understand it will happen when it happens though. That's the way of
Linux development!

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 16.14, Mark Knecht wrote:
[...]
> > BTW, priorities is what I use to keep sound effects from killing
> > long notes in in-game music and stuff like that. Simple and
> > handy, and works well as a generic improvement of the voice
> > stealing system. You can't (ab)use it to make polyphonic patches
> > monophonic, though.
>
> I think priorities could address my request. If the first X number
> of voices for any gig were high priority, then the piano's 50th
> note couldn't steal the violin's 1st note no matter how soft it
> was.

That should work - and it has the advantage of not having to figure=20
out some "sensible" number of voices to reserve for each gig, MIDI=20
port, MIDI channel or whatever.


[...]
> > Before I do that, though, I should probably benchmark the code
> > and see what kind of CPU time ratio there is between the control
> > stuff and the voice mixers... :-)
>
> I made this point once before, but I don't think anyone responded
> to it. If I benchmark the number of voices used in GSt and LS to
> render that jazz piano ogg I've posted then the release samples are
> FAR more important from a CPU/disk usage point of view than the
> main key strike notes.

As expected... Those slow releases and stuff (whether they're just=20
looping + envelopes, or special samples) are the main reason why h/w=20
synths have 64-256 voices these days, I think.


> (Active state? Note on state? What term should I
> use?)

I would suggest a separation of EG/voice states and MIDI terminology.=20
NoteOn, NoteOff and various ControlChange events are just ways of=20
suggesting what the EG should do. Depending on the patch, it may=20
react instantly, react based on what state it's in or ignore events=20
entirely. Nothing says that NoteOff is special. Lots of instruments=20
don't have a corresponding function, or releasing a keyboard key to=20
stop a note just doesn't feel right; it may make more sense to use=20
NoteOn only and use low velocities for muting notes. Whatever.

Put in an abstraction layer between MIDI and the voice state machine,=20
and try to come up with terminology that doesn't seem to suggest that=20
some MIDI events directly affect the state of the EG. (I have some=20
cleaning up to do in that area in Audiality too, I think.)


> I think that doing very much benchmarking before release samples
> are included is only going to lead to doing it again. In the piano
> ogg above, what you hear from LS today is only 10-15% of what GSt
> is doing with the same MIDI file.

Those 85-90% doesn't add *that* much to the experience, though! ;-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Mon, 2004-01-12 at 06:56, David Olofson wrote:

> > I think this is related to GigaStudio's block chord note stealing.
> 
> Can you expand on that?
> 
> 

GSt has a setting for the number of notes to use in 'Block Chord
Stealing'. I've personally never known how to best set it, so I think I
have it at about 10 notes or so, but that's just superstition.

I've not bothered to look in the help files to see what it really does.

- Mark

RE: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Mon, 2004-01-12 at 06:40, Peter E. Roos wrote:
> I believe the same functionality was already mentioned here in the
> ongoing discussions yesterday and today.
> 
> Maybe it is an option to distinguish between SAME note stealing and
> DIFFERENT note stealing, also... ;-)
> I think this is related to GigaStudio's block chord note stealing.
> 
> And, I believe this is probably already on the developers minds: treat
> the notes differently based on where they are in the ADSR in the note
> stealing process.
> 
> I guess this can a rather intricate set of rules.
> 
> Bruce is quite close to the developers, so some of his notes surely go
> beyond being educated guesses.
> 
> Regards,
> 
> Peter

Good points one and all.

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Mon, 2004-01-12 at 02:49, David Olofson wrote:
> > This does raise one unsolved issue I've seen with LS. To date I
> > think LS has no mechanism for releasing the oldest notes when it
> > reaches its maximum note count. Press sustain and start hitting
> > keys. Eventually you get messages about not being able to play
> > notes.
> 
> Or "voice stealing", as it's usually called... When allocating a new 
> voice, I just
> 	1) look for free voices
> 	2) look for the softest voice with same or lower priority
> 	3) steal the lowest priority voice (same or lower)
> 	4) fail
> 
> Now that I think of it, I'm not quite sure what I was thinking there, 
> around steps 2 and 3. Hmm... It should probably look like this:
> 
> 	1) look for free voices
> 	2) look for softer voices with same or lower priority
> 	3) use the softest voice with same or lower priority
> 	4) fail
> 
> (That is, first try to find a softer voice. If that fails, just use 
> the softest one found.)

In my simple mind I was thinking last night (when I wrote this) of the
way LS works today with a single gig library and not the way it's going
to work in the future with many gig libraries. (I hope!)

I would like to request that as a starting point the developers follow
the logic of what you are presenting here Dave, but with one small
addition. Please consider guaranteeing a specific minimum number of
voices to each gig library that is loaded. This would help ensure that a
soft violin in the background doesn't have all it's notes stolen by a
loud piano using sustain that already has 99% of the notes anyway.


> BTW, priorities is what I use to keep sound effects from killing long 
> notes in in-game music and stuff like that. Simple and handy, and 
> works well as a generic improvement of the voice stealing system. You 
> can't (ab)use it to make polyphonic patches monophonic, though.

I think priorities could address my request. If the first X number of
voices for any gig were high priority, then the piano's 50th note
couldn't steal the violin's 1st note no matter how soft it was.

> > LS needs to be able to release the oldest notes to that new notes
> > can be played. Generally it will be better to get a release or
> > something from very old notes going away vs. not playing the newest
> > notes.
> 
> Right, but don't forget to actually check whether the voices just have 
> a slow release, or if they're in the sustain state, waiting for 
> note-off. 

Right. Good point.

> That reminds me; I once had this idea about "voice unstealing".
> 
> I'm thinking about implementing it in Audiality, using dummy voices to 
> keep the EGs and stuff alive and running, until there are free 
> physical voices available. The dummy voices would not mix or 
> anything, but just do what they need to keep track of the current 
> pitch, volume, playback position etc, so they can force load a 
> physical voice at any time.
> 
> Before I do that, though, I should probably benchmark the code and see 
> what kind of CPU time ratio there is between the control stuff and 
> the voice mixers... :-)
> 

I made this point once before, but I don't think anyone responded to it.
If I benchmark the number of voices used in GSt and LS to render that
jazz piano ogg I've posted then the release samples are FAR more
important from a CPU/disk usage point of view than the main key strike
notes.

Currently, that piano piece uses about 90 voices max in GSt, while the
same piece uses only 10-12 voices in LS today. With no release samples
you would not expect a piano (without sustain) to every use more than 10
notes, and indeed it doesn't. However, once release samples are included
the faster melodic runs can end up with many voices active in the
release state with just a few new notes in the key press state. (Active
state? Note on state? What term should I use?)

I think that doing very much benchmarking before release samples are
included is only going to lead to doing it again. In the piano ogg
above, what you hear from LS today is only 10-15% of what GSt is doing
with the same MIDI file.

- Mark

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 15.40, Peter E. Roos wrote:
> I believe the same functionality was already mentioned here in the
> ongoing discussions yesterday and today.
>
> Maybe it is an option to distinguish between SAME note stealing and
> DIFFERENT note stealing, also... ;-)

Yes, that can differ a lot between instruments. Many real instruments=20
respond to "retrigging" by adding overtones that are not there when=20
starting a note from silence. Physical modelling can simulate that=20
using a single "voice" per key/string/whatever, but a sampler or=20
other wavetable synth generally has to fake it one way or another.

That said, it's not really about stealing, in the same sense as the=20
"out of voices emergency solution" - although with certain patches,=20
you *could* end up stealing your own voice, sort of. It think the=20
normal behavior would be things like:

=09* Explicitly make your voice stop playing, and then
=09  start playing a new waveform. (Causes some delay.)

=09* Do something funny with the envelope, but just let
=09  the oscillator run.

=09* Set the old voice in release state, and then start
=09  a new voice, leaving the old voice to die alone.
=09  (This is effectively what you do if you want the
=09  first alternative, but without the note-on delay.)


> I think this is related to GigaStudio's block chord note stealing.

Can you expand on that?


> And, I believe this is probably already on the developers minds:
> treat the notes differently based on where they are in the ADSR in
> the note stealing process.

Though checking the EG isn't enough, as the waveform may affect the=20
output level more than the EG sometimes.

I use simple peak level meters in Audiality, but I don't know if=20
that's a suficient or effective solution. They just happened to be=20
there when I hacked the voice stealing code... (The meters were=20
thrown in for some audio debugging eyecandy that you can see in debug=20
builds of Kobo Deluxe. :-)=20


> I guess this can a rather intricate set of rules.

To say the least... It's hard enough to figure out what *actually* is=20
the least audible voice - and that's just the beginning!


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

RE: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Peter E. R. <pet...@de...>]

I believe the same functionality was already mentioned here in the
ongoing discussions yesterday and today.

Maybe it is an option to distinguish between SAME note stealing and
DIFFERENT note stealing, also... ;-)
I think this is related to GigaStudio's block chord note stealing.

And, I believe this is probably already on the developers minds: treat
the notes differently based on where they are in the ADSR in the note
stealing process.

I guess this can a rather intricate set of rules.

Bruce is quite close to the developers, so some of his notes surely go
beyond being educated guesses.

Regards,

Peter

-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of
Mark Knecht
Sent: Monday, January 12, 2004 15:30
Cc: 'Linux-Sampler'
Subject: RE: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)


On Sun, 2004-01-11 at 23:54, Peter Roos wrote:
> Bruce Richardson once explained on the NS forum that GigaStudio also
has a
> clever mechanism for releasing (I guess "old") notes whose volume is
nearly
> zero. That might be an interesting alternative (or addition) to a
scheme of
> stopping oldest notes (which might be looping at max volume).
> 
> Cheers,
> 
> Peter Roos
> 
Peter,
   Good to have you here and thanks for the pointer. I'll have to go
look for Bruce's description. He's generally quite a good guy to get
info from.

Thanks,
Mark



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

RE: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Sun, 2004-01-11 at 23:54, Peter Roos wrote:
> Bruce Richardson once explained on the NS forum that GigaStudio also has a
> clever mechanism for releasing (I guess "old") notes whose volume is nearly
> zero. That might be an interesting alternative (or addition) to a scheme of
> stopping oldest notes (which might be looping at max volume).
> 
> Cheers,
> 
> Peter Roos
> 
Peter,
   Good to have you here and thanks for the pointer. I'll have to go
look for Bruce's description. He's generally quite a good guy to get
info from.

Thanks,
Mark

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 01.50, Mark Knecht wrote:
> On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote:
> > > =09* Is Delay a minimum note-off->release delay,
> > > =09  the maximum duration of the sustain state,
> > > =09  or what? (Both seem useful to me...)
> >
> > That 2nd "D" is actually Decay2. It's an exponential fall from
> > the last Decay1 level to the first level of the Release stage.
> > Decay2 will only become applied in case this "infinite sustain"
> > is disabled, but I'm not that sure. Maybe Mark can confirm that?
>
> I believe this is a correct description.
>
> With Infinite Sustain enabled Decay 2 is not used.
>
> With Infinite Sustain disabled, Decay 2 begins at the end of Decay
> 1. This appears (in my mind) to create a first, normally faster
> decay region like everyone is used to. After that first decay
> period, Decay 2 kicks in and GSt will then does a second decay
> period that takes you down to 0 volume. I think the intention here
> is to ensure that all notes eventually go to zero even if their
> keys are never released.

Actually, I think the intention is to make it easy to program natural=20
envelopes for looping samples. Nature tends to be exponential rather=20
than linear. :-)

And indeed, I *am* having trouble with the linear envelopes in=20
Audiality, even with the off-line synth, which has multi-section EGs.=20
Just look at the cymbals and stuff like that... *hehe* There's a new=20
EG output transformation feature now, but it doesn't seem to do the=20
job well enough. Could have screwed something up there, though; that=20
feature has hardly been tested.


> This does raise one unsolved issue I've seen with LS. To date I
> think LS has no mechanism for releasing the oldest notes when it
> reaches its maximum note count. Press sustain and start hitting
> keys. Eventually you get messages about not being able to play
> notes.

Or "voice stealing", as it's usually called... When allocating a new=20
voice, I just
=091) look for free voices
=092) look for the softest voice with same or lower priority
=093) steal the lowest priority voice (same or lower)
=094) fail

Now that I think of it, I'm not quite sure what I was thinking there,=20
around steps 2 and 3. Hmm... It should probably look like this:

=091) look for free voices
=092) look for softer voices with same or lower priority
=093) use the softest voice with same or lower priority
=094) fail

(That is, first try to find a softer voice. If that fails, just use=20
the softest one found.)


Anyway, I just brutally kill stolen voices. It appears that quite a=20
few h/w synths do that as well, but that doesn't make it an=20
acceptable solution, IMHO. One should use some "low cost" temporary=20
voice mixer or something, to allow the stolen voice to die without=20
clicking.


BTW, priorities is what I use to keep sound effects from killing long=20
notes in in-game music and stuff like that. Simple and handy, and=20
works well as a generic improvement of the voice stealing system. You=20
can't (ab)use it to make polyphonic patches monophonic, though.

Some Roland synths use a "voice reserve" system instead, which allows=20
you to allocate a fixed number of voices for each part (ie "MIDI=20
channel", sort of). That has other limitations, but it sort of does=20
the job, unless you're very low on voices and have many parts. All=20
parts without voice reserves just fight for the remaining voices.


> LS needs to be able to release the oldest notes to that new notes
> can be played. Generally it will be better to get a release or
> something from very old notes going away vs. not playing the newest
> notes.

Right, but don't forget to actually check whether the voices just have=20
a slow release, or if they're in the sustain state, waiting for=20
note-off. However, even if you do that, there's always the risk of=20
stealing the wrong voice. You'd probably have to do a continuous=20
spectrum analysis of all playing voices to reliably tell which one is=20
the least audible - and even then, you can't tell whether the note=20
you just killed will be the only one still playing a second from now!=20
:-)

That reminds me; I once had this idea about "voice unstealing".

I'm thinking about implementing it in Audiality, using dummy voices to=20
keep the EGs and stuff alive and running, until there are free=20
physical voices available. The dummy voices would not mix or=20
anything, but just do what they need to keep track of the current=20
pitch, volume, playback position etc, so they can force load a=20
physical voice at any time.

Before I do that, though, I should probably benchmark the code and see=20
what kind of CPU time ratio there is between the control stuff and=20
the voice mixers... :-)


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[David O. <da...@ol...>]

On Monday 12 January 2004 00.55, Christian Schoenebeck wrote:
> Es geschah am Sonntag, 11. Januar 2004 23:20 als David Olofson=20
schrieb:
> > On Sunday 11 January 2004 18.10, Christian Schoenebeck wrote:
> > [..]
> >
> > > PADSDR
> >
> > [..]
> >
> > ???-Attack-Decay-Sustain-Delay-Release?
> >
> > Some questions:
> > =09* What's the first state?
>
> Sorry, that's just the PreAttack value, thus the value from which
> the Attack stage will start.

I see. Turns out I have that in Audiality as well, though I didn't=20
remember. :-) (I usually start at 0 with short looped waveforms, to=20
avoid clicks. The timing is sample accurate, so you can still make=20
very fast attacks.)

There are 10 parameters total, actually; not just DAHDSR. (Those are=20
just the *states* anyway, right?) Here's the doc from enums.h:

/*
 * DAHDSR envelope generator parameters:
 *
 *   Level
 *     ^
 *     |         __L1__
 *     |        /|    |\
 *     |       / |    | \
 *     |__L0__/  |    |  \__L2__
 *     |     |   |    |   |    |\
 *     |  D  | A | H  | D | S  |R\
 *     |_____|___|____|___|____|__\____\
 *     |     |   |    |   |    |   |   / Time
 *      DELAY T1  HOLD T2   T3  T4
 *
 * State by state description:
 *
 *      D: Set to L0, and hold for DELAY seconds.
 *      A: Ramp to L1 over T1 seconds.
 *      H: Hold at L1 for HOLD seconds.
 *      D: Ramp to L2 over T2 seconds.
 *      S: if T3 < 0
 *              Hold at L2 until CE_STOP is received.
 *         else
 *              Hold at L2 for T3 seconds.
 *      R: Ramp to 0 over T3 seconds.
 *
 * If T3 is set to a negative value, sustain lasts until
 * a CE_STOP event is received. If T3 is 0 of higher,
 * sustain lasts for T3 seconds.
 *
 * The EG will *always* load L0, but from then on, if a
 * phase has a zero duration, that phase is skipped.
 * Note that skipping any of the A, D and R phases will
 * produce clicks, unless the adjacent levels are
 * identical.
 *
 * In some cases, it's desirable that the EG immediately
 * skips to the release phase when a CE_STOP event is
 * received, whereas in other cases, this would result
 * in problems with very short notes. Therefore, there is
 * a boolean control 'ENV_SKIP' that make it possible to
 * specify which behavior is desired.
 * '1' will make the EG skip to release upon receiving
 * CE_STOP. '0' will result in the EG taking no action
 * on CE_STOP until the sustain phase is reached the
 * normal way.
 * 'ENV_SKIP' has no effect if "timed sustain" is used;
 * T3 must be < 0, or CE_STOP is entirely ignored.
 *
 */

That is, it's pretty much flat section, ramped section, flat section,=20
=2E.. etc, and a switch for "interactive sustain".


[...]
> > =09* Why no Hold between Attack and Decay?
> > =09  (Nice for tweaking fast, percussive sounds.)
>
> Yes, that will definitely be added. The Giga format has a flag for
> this in the patch format to turn this on / off (for those who don't
> know what we're talking about - this "hold" parameter will postpone
> the first Decay stage until the sample playback reached the loop
> begin).

That's yet another variant, though. My "hold" is E-mu (IIRC)=20
terminology, and is just the duration of the flat section between the=20
attack and the decay.

The Giga variant sounds handy as well, though. How about some system=20
that allows all sorts of events to trigger and/or "permit" EG state=20
changes? For example, one would handle the sustain pedal in a similar=20
way to how I handle note-off in Audiality. Any control could be=20
linked to any envelope section.


> But again, I'm just very priority driven at the moment. I
> first do all the basic things with the highest priority and
> postpone fine adjustments later if that doesn't hurt the design.

Yeah. That's why I ended up with the DAHDSR variant I'm using. I just=20
realized eventually, that the code would have been smaller, cleaner=20
and more flexible if I had went for the generic version right away.=20
There's a pretty long switch() in there now, and the cases are=20
confusingly similar. :-)


> > =09* Is Delay a minimum note-off->release delay,
> > =09  the maximum duration of the sustain state,
> > =09  or what? (Both seem useful to me...)
>
> That 2nd "D" is actually Decay2. It's an exponential fall from the
> last Decay1 level to the first level of the Release stage. Decay2
> will only become applied in case this "infinite sustain" is
> disabled, but I'm not that sure. Maybe Mark can confirm that?

Ah. Another nice feature. :-)


[...roadmap...]

Makes a lot of sense. Don't get sidetracked by my suggestions. :-) I'm=20
just brainstorming, basically, thinking about stuff that is or might=20
be useful in LS as well as Audiality.


BTW, I released Audiality 0.1.1 the other day, in case you haven't=20
noticed. The current version of the EG is in there (a_patch.c), in=20
case the code could be of use in any way.


//David Olofson - Programmer, Composer, Open Source Advocate

=2E- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

RE: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Peter R. <pet...@de...>]

Bruce Richardson once explained on the NS forum that GigaStudio also has a
clever mechanism for releasing (I guess "old") notes whose volume is nearly
zero. That might be an interesting alternative (or addition) to a scheme of
stopping oldest notes (which might be looping at max volume).

Cheers,

Peter Roos

-----Original Message-----
From: Mark Knecht [mailto:mar...@co...] 
Sent: Monday, January 12, 2004 1:51
To: Christian Schoenebeck
Cc: Linux-Sampler
Subject: Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)


On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote:

> > 	* Is Delay a minimum note-off->release delay,
> > 	  the maximum duration of the sustain state,
> > 	  or what? (Both seem useful to me...)
> 
> That 2nd "D" is actually Decay2. It's an exponential fall from the last
Decay1 
> level to the first level of the Release stage. Decay2 will only become 
> applied in case this "infinite sustain" is disabled, but I'm not that
sure. 
> Maybe Mark can confirm that?

I believe this is a correct description. 

With Infinite Sustain enabled Decay 2 is not used.

With Infinite Sustain disabled, Decay 2 begins at the end of Decay 1.
This appears (in my mind) to create a first, normally faster decay
region like everyone is used to. After that first decay period, Decay 2
kicks in and GSt will then does a second decay period that takes you
down to 0 volume. I think the intention here is to ensure that all notes
eventually go to zero even if their keys are never released.

This does raise one unsolved issue I've seen with LS. To date I think LS
has no mechanism for releasing the oldest notes when it reaches its
maximum note count. Press sustain and start hitting keys. Eventually you
get messages about not being able to play notes.

LS needs to be able to release the oldest notes to that new notes can be
played. Generally it will be better to get a release or something from
very old notes going away vs. not playing the newest notes.

Cheers,
Mark





-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Linuxsampler-devel mailing list
Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel

Re: [Linuxsampler-devel] Latest CVS commit

[Vladimir S. <ha...@so...>]

Christian,

I've looked a bit more into this problem.
I think the root cause is in AudioThread::ProcessControlChange()
In particular, hSustainPtr can be set for a key that is still pressed.
In then becomes impossible for ProcessNoteOff() to do the right thing . . .

I tried to put these lines in AudioThread::ProcessControlChange():
                SustainedKeyPool->free(pMIDIKeyInfo[*key].pSustainPoolNode);
                pMIDIKeyInfo[*key].pSustainPoolNode = NULL;
                pMIDIKeyInfo[*key].Sustained   = false;
                pMIDIKeyInfo[*key].hSustainPtr = NULL;
into the if statement just above:
if (!pMIDIKeyInfo[*key].KeyPressed) { // release the voices on the key, 
if the key is not pressed anymore
so that it will not be done for keys that are still pressed.
I gave it a very quick test and it looks like it's working correctly.

Regards,
Vladimir.

PS: above is written at 2am in the morning under pressure to shut PC 
down immediately therefore it can't be trusted :)

Vladimir Senkov wrote:

> Christian,
>
> Awesome!!!
> I can't hear any noises at all with that free Steinway sample and 
> default settings.
>
> But . . . I think a bug got introduced in the process.
> Occasionally, some notes will not release completely. They'll get 
> stuck in a state where i can still hear them but their volume is lower 
> than usual.
> If i play the same note again it goes away.
> Kinda feels like a stuck key :) But it's not, because when i play the 
> same thing with old ls (pre cvs update) i don't get into that state.
>
> After a while i found a way to reproduce: (other ways may exist also)
> 1) play and hold note. (voices: 1)
> 2) apply and hold sustain.
> 3) release the note (keeps playing on sustain)
> 4) play and hold the same note again (voices: 2)
> 4) release sustain
> 5) apply sustain (hold)
> 6) release the note
> 7) release sustain. (voices: 2!)
> Voices will still be allocated and playing at this point!
>
> I'd love to implement PADSDR but i hope it's not very urgent as i need 
> to do a bit of reading first.
>
> Regards,
> Vladimir.
>
> Christian Schoenebeck wrote:
>
>> Changes:
>>
>>     -  There was still this annoying problem that some .gig 
>> instruments were
>>        detuned. I hope I have fixed this now. If you have still a 
>> .gig that
>>        sounds detuned, please let me know!
>>
>>     - As promised I finished an initial version of the amplitude 
>> envelope
>>        generator (EG1), so far only a simple ASR one. Extending it to 
>> a PADSDR
>>        one (as used in Gigasampler) is quite easy. If anybody likes 
>> to do this
>>        task, you just have to improve the EG_VCA class 
>> (src/eg_vca.cpp). Vladimir
>>        perhaps?
>>        The EG has a minimum release time, in case the release time 
>> given by the
>>        gig file is 0s for example. Without this min. release time we 
>> would again
>>        have the click problem in case of zero release times when the 
>> voice will
>>        be released before it's sample end. This min. release time is 
>> defined in
>>        line 32 of src/eg_vca.h and there's another #define which sets 
>> the bottom
>>        value limit of the Exp curve, thus also defines the end of the 
>> EG curve in
>>        general. These two #define values still have to be adjusted to 
>> good values
>>
>> CU
>> Christian
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Perforce Software.
>> Perforce is the Fast Software Configuration Management System offering
>> advanced branching capabilities and atomic changes on 50+ platforms.
>> Free Eval! http://www.perforce.com/perforce/loadprog.html
>> _______________________________________________
>> Linuxsampler-devel mailing list
>> Lin...@li...
>> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>>
>>  
>>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Perforce Software.
> Perforce is the Fast Software Configuration Management System offering
> advanced branching capabilities and atomic changes on 50+ platforms.
> Free Eval! http://www.perforce.com/perforce/loadprog.html
> _______________________________________________
> Linuxsampler-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
>

Re: [Linuxsampler-devel] Roadmap (was: Latest CVS commit)

[Mark K. <mar...@co...>]

On Sun, 2004-01-11 at 15:55, Christian Schoenebeck wrote:

> > 	* Is Delay a minimum note-off->release delay,
> > 	  the maximum duration of the sustain state,
> > 	  or what? (Both seem useful to me...)
> 
> That 2nd "D" is actually Decay2. It's an exponential fall from the last Decay1 
> level to the first level of the Release stage. Decay2 will only become 
> applied in case this "infinite sustain" is disabled, but I'm not that sure. 
> Maybe Mark can confirm that?

I believe this is a correct description. 

With Infinite Sustain enabled Decay 2 is not used.

With Infinite Sustain disabled, Decay 2 begins at the end of Decay 1.
This appears (in my mind) to create a first, normally faster decay
region like everyone is used to. After that first decay period, Decay 2
kicks in and GSt will then does a second decay period that takes you
down to 0 volume. I think the intention here is to ensure that all notes
eventually go to zero even if their keys are never released.

This does raise one unsolved issue I've seen with LS. To date I think LS
has no mechanism for releasing the oldest notes when it reaches its
maximum note count. Press sustain and start hitting keys. Eventually you
get messages about not being able to play notes.

LS needs to be able to release the oldest notes to that new notes can be
played. Generally it will be better to get a release or something from
very old notes going away vs. not playing the newest notes.

Cheers,
Mark