Menu
▾
▴
linuxsampler-devel
|
From: Andreas P. <and...@lk...> - 2004-12-04 14:55:33
|
Hello,
If a key is pressed, released and then pressed again before the release
of the first note has finished, the release of the first note is
canceled - the first note continues to play until the second note is
released. Why is that? Is it intentional? It doesn't seem like GS
behaves like that.
As the fix for this is to simply remove some code, I have a feeling I'm
missing something. These lines from Engine::ProcessNoteOn are the ones I
would like to remove:
// cancel release process of voices on this key if needed
if (pKey->Active && !SustainPedal) {
RTList<Event>::Iterator itCancelReleaseEvent =
pKey->pEvents->allocAppend();
if (itCancelReleaseEvent) {
*itCancelReleaseEvent = *itNoteOnEvent;
// copy event
itCancelReleaseEvent->Type =
Event::type_cancel_release; // transform event type
}
else dmsg(1,("Event pool emtpy!\n"));
}
/Andreas
|
|
From: Christian S. <sch...@so...> - 2004-12-05 12:38:52
|
Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb: > Hello, Hi and sorry for the late response. > If a key is pressed, released and then pressed again before the release > of the first note has finished, the release of the first note is > canceled - the first note continues to play until the second note is > released. Why is that? Is it intentional? It doesn't seem like GS > behaves like that. Yes, that's in fact intentional. Because it's a more natural behaviour. If you release a key on a real piano and e.g. press the sustain pedal immediately after that it would also first damp the wave but then when the pedal is pressed would let the wave fade out slowly at the reached amplitude level when the pedal was pressed. So I don't agree to remove that, but we can of course make that a compile time option if you like. CU Christian |
|
From: Andreas P. <and...@lk...> - 2004-12-05 13:00:50
|
Christian Schoenebeck wrote: > Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb: >>If a key is pressed, released and then pressed again before the release >>of the first note has finished, the release of the first note is >>canceled - the first note continues to play until the second note is >>released. Why is that? Is it intentional? It doesn't seem like GS >>behaves like that. > > > Yes, that's in fact intentional. Because it's a more natural behaviour. If you > release a key on a real piano and e.g. press the sustain pedal immediately > after that it would also first damp the wave but then when the pedal is > pressed would let the wave fade out slowly at the reached amplitude level > when the pedal was pressed. Yes, this is the "Piano release mode" in GS, and I agree it's a nice feature. But it is handled fine in Engine::ProcessControllChange. The code in ProcessNoteOn is not needed for this if I understand things correctly? For me, the ProcessNoteOn code only seems to eat polyphony and make the second note unnecessarily loud. /Andreas |
|
From: Christian S. <sch...@so...> - 2004-12-05 13:14:24
|
Es geschah am Sonntag 05 Dezember 2004 14:00 als Andreas Persson schrieb: > Christian Schoenebeck wrote: > > Es geschah am Samstag 04 Dezember 2004 15:55 als Andreas Persson schrieb: > >>If a key is pressed, released and then pressed again before the release > >>of the first note has finished, the release of the first note is > >>canceled - the first note continues to play until the second note is > >>released. Why is that? Is it intentional? It doesn't seem like GS > >>behaves like that. > > > > Yes, that's in fact intentional. Because it's a more natural behaviour. > > If you release a key on a real piano and e.g. press the sustain pedal > > immediately after that it would also first damp the wave but then when > > the pedal is pressed would let the wave fade out slowly at the reached > > amplitude level when the pedal was pressed. > > Yes, this is the "Piano release mode" in GS, and I agree it's a nice > feature. But it is handled fine in Engine::ProcessControllChange. The > code in ProcessNoteOn is not needed for this if I understand things > correctly? ProcessControlChange() only handles the sustain pedal case. ProcessNoteOn() handles the case when the same key was triggered instantly after releasing the same key. So this make sense. > For me, the ProcessNoteOn code only seems to eat polyphony and make the > second note unnecessarily loud. Again, we can make that a compile time option if you like. CU Christian |
|
From: Andreas P. <and...@lk...> - 2004-12-05 14:22:07
|
Christian Schoenebeck wrote: > ProcessControlChange() only handles the sustain pedal case. ProcessNoteOn() > handles the case when the same key was triggered instantly after releasing > the same key. So this make sense. Sorry for being so stubborn, but I'm not sure I understand when the second case adds any realism? I have done measurements with GS 2.5, and if they are correct, the cancel_release is done in the sustain pedal case (if "Piano release mode" is on), but not in the retrigger case. > Again, we can make that a compile time option if you like. OK, but what will be the default? :) /Andreas |
|
From: Christian S. <sch...@so...> - 2004-12-05 14:42:47
|
Es geschah am Sonntag 05 Dezember 2004 15:22 als Andreas Persson schrieb: > Christian Schoenebeck wrote: > > ProcessControlChange() only handles the sustain pedal case. > > ProcessNoteOn() handles the case when the same key was triggered > > instantly after releasing the same key. So this make sense. > > Sorry for being so stubborn, but I'm not sure I understand when the > second case adds any realism? There's nothing to excuse, doubts are often productive. I guess you don't see a realism, because you assume the 2nd key trigger causes a new voice of approx. the same amplitude or even higher than the first one. But imagine the following case: you trigger key C3 the first time with a velocity of 127, then you release key C3 and immediately after that press C3 again, but this time with a velocity of 1. If we do what you claimed and remove those lines, you will hear nothing on the 2nd key trigger. With current implementation though you still here the first voice. Which makes sense, doesn't it? > > Again, we can make that a compile time option if you like. > > OK, but what will be the default? :) I vote against that being the default behaviour. But of course if I'm alone with that opinion I accepted it even as default behaviour. CU Christian |
|
From: Andreas P. <and...@lk...> - 2004-12-05 17:12:00
|
Christian Schoenebeck wrote: > But imagine the following case: you trigger key C3 the first time with a > velocity of 127, then you release key C3 and immediately after that press C3 > again, but this time with a velocity of 1. > > If we do what you claimed and remove those lines, you will hear nothing on the > 2nd key trigger. With current implementation though you still here the first > voice. Which makes sense, doesn't it? Perhaps you're right. I wish I had a real piano nearby... Anyway, I have now played a piano gig in LS with and without the cancel release in note on (that is, a practical test as opposed to the theoretical record-and-stare-at-zoomed-in-waveforms tests I did before), and: the difference is so subtle to me that my opinion on this almost faded away completely. Just in case other type of instruments would behave differently, do you think it would be OK to insert "if (pInstrument->PianoReleaseMode)" around both cancel_release cases? > I vote against that being the default behaviour. But of course if I'm alone > with that opinion I accepted it even as default behaviour. My only argument for removing the lines per default would be that it makes the gig engine theoretically sound a little bit more like GS. /Andreas |
|
From: Mark K. <mar...@gm...> - 2004-12-05 17:15:19
|
On Sun, 5 Dec 2004 15:26:10 +0100, Christian Schoenebeck <sch...@so...> wrote: > Es geschah am Sonntag 05 Dezember 2004 15:22 als Andreas Persson schrieb: > > Christian Schoenebeck wrote: > > > ProcessControlChange() only handles the sustain pedal case. > > > ProcessNoteOn() handles the case when the same key was triggered > > > instantly after releasing the same key. So this make sense. > > > > Sorry for being so stubborn, but I'm not sure I understand when the > > second case adds any realism? > > There's nothing to excuse, doubts are often productive. > > I guess you don't see a realism, because you assume the 2nd key trigger causes > a new voice of approx. the same amplitude or even higher than the first one. > > But imagine the following case: you trigger key C3 the first time with a > velocity of 127, then you release key C3 and immediately after that press C3 > again, but this time with a velocity of 1. > > If we do what you claimed and remove those lines, you will hear nothing on the > 2nd key trigger. With current implementation though you still here the first > voice. Which makes sense, doesn't it? > > > > Again, we can make that a compile time option if you like. > > > > OK, but what will be the default? :) > > I vote against that being the default behaviour. But of course if I'm alone > with that opinion I accepted it even as default behaviour. > > CU > Christian > Hi, Fairly long time since I've posted much. Speaking logically only, and not musically or even about GSt or LS specifically, I think it depends on what sort of instrument you are modeling. If the instrument is something physical where-in the second event uses the same physical entity to make the sound, then the second event should override the first. The quiet note replaces the loud note. This is the way a synth with limited oscillator count would work and probably the way GSt works when doing voice stealing. However the piano is difficult. Playing a second note on middle C does not eliminate the first note. (sustain pedal held) The second note is additive, and additive in a non-intuitive way. Actually, whatever the effect of the first and second events are, I would say they both end at the same time. (Again, sustain pedal held.) I don't think the loud note finishes any sooner than the soft note, does it? In fact the soft note might actually finish sooner implying velocity effects the overall length of the envelope. If the instrument being modeled is a synth, and assuming unlimited oscillator count, then there are just two separate events that take place in parallel. Probably this ramble isn't adding anything to the knowledge base other than to say I'm out here reading. Take care, Mark |
|
From: Mark K. <mar...@gm...> - 2004-12-06 01:35:21
|
On Sun, 5 Dec 2004 17:06:24 -0500, Vladimir Senkov <ha...@gm...> wrote: > Mark, > > If i understand what you mean by "sync" correctly . . . > How is playing two notes in sync different from playing one note? > In other words, it when the second note is triggered we could just > figure out the parameters that need to be brought fromt he first note > to the second and then we could just start playing the second note and > not play the first one anymore. > But clearly for some instruments it is not going to work well because > the form of the wave could change dramatically in time. So playing two > notes of the same but starting from different position is in fact more > like playing two different notes. So you can't really "sync" them up . > . . > So I think I'm not getting the idea across very well. Let's take an example of a gig file that holds a simple sine wave. Assume I hit some key that generates a 1000Hz sine wave. I hit the key and LS starts playing the note, along with it's envelope. Nothing new here. That's what LS does today. Now assume at some random time I play a second of the same note. Again 1KHz. It starts playing with it's attendant envelope. The two signals are summed together to create the final output. That's what we do today. The issue to see here is that the exact time the second note starts can, in this simple case, have a dramatic effect on what you hear. If I play the second note exactly at a time n*1/1000 seconds later, then the second note reinforces the first and you get a signal that's twice as loud. However, if I play the note at n*1/2000 seconds later, where n is odd, then the two notes exactly cancel and you get no sound! The first sine wave is going down at the very instant that the second is going up. (A 180 degree phase shift) The second example is something that cannot happen with a real piano string. Whatever the resultant waveform clearly the string is still vibrating. There are not two separate sine waves of the same frequency on the same string. There is one resultant vibration. As a thought experiment I was considering what this means in LS. All I'm suggesting, as an idea, and not as a real suggestion for developers to implement, is that when the first note is played we would remember the time in which it started. From that time forward, until that note was finished playing, we would only start playing new notes (for the same MIDI key) at n*1/1000 seconds later. (Assuming the key was supposed to generate a 1KHz fundamental.) If we did that then the two notes would be 'in sync' or would be playing with a 0 degree phase shift. This means that the two sets of samples are being read and played back in sync. The way playing two notes is different from playing one note is that the second note is reading the starting samples while the first note is reading samples further on in the stream. The idea is that we keep the two streams separated by a value equal to some multiple of their fundamental frequencies. I can elaborate on this more if required. I hope this helps explain the idea anyway. It's just an idea but I think it's similar to synced oscillators some newer hardware synths. I'm just extending it to samplers. - Mark |
|
From: Vladimir S. <ha...@gm...> - 2004-12-06 05:50:48
|
Hi Mark, > So I think I'm not getting the idea across very well. Let's take I think i did understood and i'm not disagreeing, but i'd like to figure out a few things. > The issue to see here is that the exact time the second note starts > can, in this simple case, have a dramatic effect on what you hear. If > I play the second note exactly at a time n*1/1000 seconds later, then > the second note reinforces the first and you get a signal that's twice > as loud. However, if I play the note at n*1/2000 seconds later, where > n is odd, then the two notes exactly cancel and you get no sound! The > first sine wave is going down at the very instant that the second is > going up. (A 180 degree phase shift) agree, but only if the sample is uniform like sin(x) > The second example is something that cannot happen with a real piano > string. true. >Whatever the resultant waveform clearly the string is still > vibrating. There are not two separate sine waves of the same frequency > on the same string. There is one resultant vibration. that depends on what the definition of "IS" is :))) We could say that 2sin(x) is really sin(x)+sin(x) (and are in the same phase) can't we? > the two notes would be 'in sync' or would be playing with a 0 degree > phase shift. This means that the two sets of samples are being read > and played back in sync. for the case of simple sin(x) two playin in sync will then be sin(x) + sin(x) = 2sin(x). So that's the same one with twice the amplitude. Moreover, if the sample is just sin(x) then if the first note was hit with attack level 10 and another with attack level 20 and we (for the sake of simplicity) play 10sin(x) for the first and 20sin(x) for second we could then just play 30sin(x) for the two of them. > The way playing two notes is different from playing one note is that > the second note is reading the starting samples while the first note > is reading samples further on in the stream. If sample is sin(x) then it doesn't matter because they will be reading the same data. However if it's different then it will be really difficult to define "in sync". >The idea is that we keep > the two streams separated by a value equal to some multiple of their > fundamental frequencies. I can elaborate on this more if required. i think i understand the idea, but let's consider a few more examples. let's say a sample is something like a bell. for simplicity, let's forget about the envelope. you take a note . . . sampler plays "Bim....Bom" Now, if we play it the second time, what would be in sync for the two? Technically speaking, "Bim" in the beginning of the sample could have a period that is quite different from "Bom". So we can't really say that Bim could be "in sync" with Bom. Bell is perhaps not a very good example but i think there are many others. So for some samples it "merging" could work while for some others it could not. -- Regards, Vladimir |
|
From: Andreas P. <and...@lk...> - 2004-12-05 18:01:39
|
Mark Knecht wrote: > Speaking logically only, and not musically or even about GSt or LS > specifically, I think it depends on what sort of instrument you are > modeling. Yes, I guess that's why the "Piano release mode" in a gig file is optional. > If the instrument is something physical where-in the second > event uses the same physical entity to make the sound, then the second > event should override the first. The quiet note replaces the loud > note. This is the way a synth with limited oscillator count would work > and probably the way GSt works when doing voice stealing. If there are enough voices, GSt will play the release of the loud note along with the quiet note. > However the piano is difficult. Playing a second note on middle C > does not eliminate the first note. (sustain pedal held) The second > note is additive, and additive in a non-intuitive way. Actually, > whatever the effect of the first and second events are, I would say > they both end at the same time. (Again, sustain pedal held.) I don't > think the loud note finishes any sooner than the soft note, does it? > In fact the soft note might actually finish sooner implying velocity > effects the overall length of the envelope. Just to be sure, note that the case we've been discussing is not when the sustain pedal is being held. Instead: The second note comes so close to the note-off of the first that the first note has not finished its release yet. Then, with current LS, the first note will give up its release and continue to play at its current volume together with the second note. When the sustain pedal is held, I think both GSt and LS will handle all note-on events as separate events that run independently until their respective samples finish (or the sustain pedal is released). An exception to this is if "Self mask" option is enabled. Then, a louder note will kill a playing quiet one, to preserve polyphony. This feature is not yet in LS. The non-intuitive addition you mention, was an interesting thought. I don't think GSt has any support of it. /Andreas |
|
From: Mark K. <mar...@gm...> - 2004-12-05 19:24:45
|
On Sun, 05 Dec 2004 19:01:28 +0100, Andreas Persson <and...@lk...> wrote: > Mark Knecht wrote: > > > Speaking logically only, and not musically or even about GSt or LS > > specifically, I think it depends on what sort of instrument you are > > modeling. > > Yes, I guess that's why the "Piano release mode" in a gig file is optional. > > > If the instrument is something physical where-in the second > > event uses the same physical entity to make the sound, then the second > > event should override the first. The quiet note replaces the loud > > note. This is the way a synth with limited oscillator count would work > > and probably the way GSt works when doing voice stealing. > > If there are enough voices, GSt will play the release of the loud note > along with the quiet note. > > > > > However the piano is difficult. Playing a second note on middle C > > does not eliminate the first note. (sustain pedal held) The second > > note is additive, and additive in a non-intuitive way. Actually, > > whatever the effect of the first and second events are, I would say > > they both end at the same time. (Again, sustain pedal held.) I don't > > think the loud note finishes any sooner than the soft note, does it? > > In fact the soft note might actually finish sooner implying velocity > > effects the overall length of the envelope. > > Just to be sure, note that the case we've been discussing is not when > the sustain pedal is being held. Instead: The second note comes so close > to the note-off of the first that the first note has not finished its > release yet. Then, with current LS, the first note will give up its > release and continue to play at its current volume together with the > second note. OK, I think I missed that. With a piano this window of time is pretty small. I guess what you are talking about really is a bug if it does what I think you are saying it does. The first note must just die away or you run out of notes much more quickly. The part I'm not sure I understand from this email is whether the first note is still using it's sample base, or did it start using the second note's sample base? Clearly it must use its own samples since it may be from a different velocity group. I think it probably does. > > When the sustain pedal is held, I think both GSt and LS will handle all > note-on events as separate events that run independently until their > respective samples finish (or the sustain pedal is released). An > exception to this is if "Self mask" option is enabled. Then, a louder > note will kill a playing quiet one, to preserve polyphony. This feature > is not yet in LS. I think that possibly LS should try to improve on GSt's usability. I run into problems with GSt all the time where the addition of notes causes the overall mix to get to loud and hence it distorts. This doesn't happen as quickly when you mix loud and soft notes, but if you mix all loud notes then you end up with too much volume and the mix bus distorts. (numerically) Possibly some sort of soft compressor in the output stages of LS would help a lot in this area. > > The non-intuitive addition you mention, was an interesting thought. I > don't think GSt has any support of it. > Actually I had a much more radical thought about what the 'right' way to do some of this when we are talking about piano modeling. Again, my thinking initially was about the case where the sustain pedal is held, but some of it applies even without sustain. If we consider the piano where there is only a single middle C element (1 or more strings struck together) then I think a couple of things possibly happen: 1) Since there is only one string to vibrate then there is only one 'sample set' to play? Maybe a soft second note is really just a modification of the existing (louder) note's envelope? I'm not totally convinced of this since the second soft note may have significant harmonics in it's initial samples that we wouldn't want to miss, at least in certain cases. 2) Even if you decide that there is a second sample set to play, in the real piano the two must be sync locked to each other. The string is vibtrating and the second strike (or probably more accurately the lower volume strike) must get in sync with the first (louder) strike. I.e. - there is only one way to vibrate the string at that frequency. Since both strikes account for creating the same frequencies. (I think...) Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second later. Numerically the two would cancel each other. The first is going up while the second is going down, in sine wave terms. In the piano they do not. The second note always adds to the mix. So, either the first note gets synced to the second or the second to the first, but something must be happening physically. Is there an opportunity to make a better sounding LS by addressing this idea somehow? - Mark |
|
From: Vladimir S. <ha...@gm...> - 2004-12-05 20:23:42
|
Hi Mark, It's been awhile, nice to hear from you again! :) > Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second > later. Numerically the two would cancel each other. The first is going > up while the second is going down, in sine wave terms. In the piano > they do not. The second note always adds to the mix. So, either the > first note gets synced to the second or the second to the first, but > something must be happening physically. Modelling the "real" hammer hitting the "real" string is not easy and i don't think we have enough information from the sample file to do that. I think what happens here is not trivial. For example, let's make a very simple case: a perfect hammer hits a perfectly idle string right in the middle (note in a real piano it's not in the middle at all for most strings). Let's say for whatever reason the string ends up in a perfect sine at 400Hz. Let's say there is a certain amplitude A to this sine. So every point of the string moves at the speed of 800A/sec. But do we mean by "hits"? In reality, hammer's speed is probably in the same order as 800A/sec if not slower!. Hammer is also not small, so it hits the string in a relatively large area so that area will not be in a perfect sine. But more importanly for how long is the hammer attached to the string while hitting it? And what's going to happen during this time? If hammer hits the string in the middle, string in fact becomes two strings each likely to produce a sine at 800Hz rather than 400. Same thing is likely to happen at the time any subsequent triggering. So as far as "real" things we are trying to do my understanding is that: 1) In most samplers (GS included) if i play a note, apply sustain, release the note, then release sustain, then quickly reapply it, the note will go out of release back into sustain. That's been well tested and please correct me if i'm wrong because i firmly believe it :) 2) At the same time, if i play a note, then release it and quickly play it again . . . we have differences in implementation. So the issue is what if the first note in release stage still sounded richer than the second note. I think it really comes down to how long the release stage is and how likely is this to happen. Technically, i think it is "more correct" to treat case number 2 the same as case number 1. I think that physically when the damper comes down it affects the first sine existing in the string much more so then a hammer hitting it. Why? Because if it's larger area and longer time of contact. In other words, it's designed to do just that, reduce the amplitude of the wave asap. Hammer has more energy to it, but that just basically separates the string into two for a very short period of time and doesn't kill the initial vibration. This is all getting interesting when we consider polination between strings. In other words, it is clear that on a real piano if i hold A3 for a very long time (to the point where it's silent) and then hit A4 very loudly and immediately release A4 i'll now hear A3 again :) As far as i know, none of the samplers do any of that yet. But some of those "digital pianos" do from what i hear (from unreliable sources :). -- Regards, Vladimir |
|
From: Mark K. <mar...@gm...> - 2004-12-05 20:55:43
|
On Sun, 5 Dec 2004 15:23:32 -0500, Vladimir Senkov <ha...@gm...> wrote: > Hi Mark, > It's been awhile, nice to hear from you again! :) You too. > > > Point in case. Hit a note at 500Hz. Hit the same note exaclty 1 second > > later. Numerically the two would cancel each other. The first is going > > up while the second is going down, in sine wave terms. In the piano > > they do not. The second note always adds to the mix. So, either the > > first note gets synced to the second or the second to the first, but > > something must be happening physically. > > Modelling the "real" hammer hitting the "real" string is not easy and > i don't think we have enough information from the sample file to do > that. No, that's all far more complicated than I was intending. I was more thinking that playing two notes of the same note should be synced. If note 1 is already playing, and then note 2 is struck (the MIDI event) then look at the fundamental frequency of these notes and delay the start of the second note's samples until they would play 'in sync' with the first note's samples. In this way I was thinking the first and second note would be more 'supportive' of each other, and in some ways more like I'm guessing the real string works. This works for the case where the first note is loud and the second is soft. However, when we turn it around it's not so clear what to do. If you want the two to be in sync, then do you play the second one a bit late again? Or do you play it right away? My thought is to play them all second notes just a bit late to guarantee sync between any notes of the same value. this is all programming trick. I'm not talking about changing anything fundamental here. All we need to know is the apparent fundamental frequencies of the notes, but even this may not be obvious, or may be weird when we add tuning to the tool sets. - Mark I think |
|
From: Vladimir S. <ha...@gm...> - 2004-12-05 22:06:32
|
Mark, If i understand what you mean by "sync" correctly . . . How is playing two notes in sync different from playing one note? In other words, it when the second note is triggered we could just figure out the parameters that need to be brought fromt he first note to the second and then we could just start playing the second note and not play the first one anymore. But clearly for some instruments it is not going to work well because the form of the wave could change dramatically in time. So playing two notes of the same but starting from different position is in fact more like playing two different notes. So you can't really "sync" them up . . . Regards, Vladimir |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X