While playing back a song, one has the option to make extra sounds via the keyboard with a chosen sample, within a certain octave range. Even with 'record' off.
But if the chosen instrument is a sample, set in a loop, e.g. strings, things get not appropriate.
Once started, it keeps on playing, even after the chosen sample-nr for the keyboard has changed.
The only way to stop the looping sample-sound appears to be to stop the song.
I can't reproduce this:
- I play a empty pattern.
- I disable recording.
- I press a key and my looped sample sounds.
- I release the key and my looped sample fades as defined by the instrument fade out property, or cuts instantly if I'm not using instruments.
Maybe the sample is fading out very slowly. Try increasing the instrument's fade value to 999.
In my reproduction the looped sample keeps on sounding also after releasing the key (this is within playing in the pattern tab). It's even so, that a second hit on another key adds another loop to the running sound.
This all with the fade value on a default 0. Never used this, but after testing it appears that this fadeout is implemented on the loop itself from the start, not as a thing after stopping the sound.
While testing I found a way to stop the sound by setting off/on the loop type in the sample tab.
Quote from: "Sam_Zen"This all with the fade value on a default 0.
This behaviour is by design if the fadeout value is 0. 0 means no fade. Higher values mean faster fade. Try 999.
The fade kicks in after releasing the key, at least with IT. Maybe different with XM. Are you using IT or XM?
If that's not the problem, does this happen with all songs? If not can you make a song where it happens available?
Is there anything else you can think of that could explain why I can't reproduce the issue? Do you have envelope loops on your instrument? Releasing the key should send a note off instruction for that instrument. What happens when you release the key when the song is stopped? What happens when the instrument gets a note off from the pattern editor.
NB: if you remove focus from the pattern editor's note column between pressing the key and releasing it, the pattern editor will not receive the not off command so the note will keep playing.
Sorry for the ton of questions but please reply to as many as possible... Since I can't reproduce this, the more info you provide, the better.
Can anyone else reproduce this problem?
This is not song-dependent I think. Now I found the trick to stop this process, but before that, the looped sound even went on after I stopped playing back the song or pattern.
Quote from: "Sam_Zen"This is not song-dependent I think. Now I found the trick to stop this process, but before that, the looped sound even went on after I stopped playing back the song or pattern.
Perhaps you have the problem called "sticky keys" where NNA forces a sound to be in a virtual channel where you can't stop it?
Cus I had an ocasion where NNA couldn't be killed with a ^^ anymore. It only happened once to me in .41 and couldn't reproduce it (not really tried tho)
That's possible. Sam Zen, how intermittent or otherwise is your problem?
Does it happen with an empty song?
Indeed quite some questions, so my investigation will take some time to create the proper testconditions.
In the meantime I would like to point to a possible root of this problem :
If I choose an instrument with a looped sample while the focus is on the pattern editor, and I press the 'C'-key once,
the sound starts and keeps on doing so. If I then press the 'A'-key, the C-sound continues, while the A is added, running a second loop within the same sample, as can be seen watching the vertical lines in the sample-image.
Shouldn't it be more elegant if the C-loop stops, as soon as the A-key is pressed ?
Quote from: "Sam_Zen"I press the 'C'-key once, the sound starts and keeps on doing so. [...]
If I then press the 'A'-key, the C-sound continues, while the A is added [...].
Shouldn't it be more elegant if the C-loop stops, as soon as the A-key is pressed ?
1. I assume you have released the C key before pressing A, else you're effectively asking us to disable support for playing chords!
2. The point of this bug is that normally, the C note would enter its release phase as soon as you let go of the key - i.e. it would fade depending on envelopes etc...
So to answer your question: no, C should not stop when you press A, but when you release C. :)
Quote from: "Sam_Zen"Indeed quite some questions, so my investigation will take some time to create the proper testconditions.
Ok, sorry. Here's a recap, some of the questions should be quick to answer:
Are you seeing this consistently or intermittently?
Are you using IT or XM?
Does this happen with all songs? [yes]
If not can you make a song where it happens available? [n/a]
Does it happen with empty patterns?
Is there anything else you can think of that could explain why I can't reproduce the issue? Any unusual configuration options?
Do you have envelope loops on your instrument?
What happens when you press and release the key in the pattern editor when the song is stopped? How about in the instrument tab?
What happens when the instrument gets a note off from the pattern editor (i.e. what happens during normal playback when the instrument encounters a tracked note-off)?
If you remove focus from the pattern editor's note column between pressing the key and releasing it, the pattern editor will not receive the not off command so the note will keep playing. Could this be the problem?
Can anyone else reproduce this problem?
Quote from: "rewbs"Can anyone else reproduce this problem?
I can't reproduce this. It works as expected for me.
Wow, a lot of serious questions. In the meantime :
I use XM's. If I talk of key-use in this process I mean 'trigger' keys, not holding down, in the first place.
Part of the problems were mysteriously solved with version .42. A key release stops the looping now.
But still there are oddities. This is the file using as an example (http://www.samshuijzen.nl/sam/plainmods/Bedfox4s.xm), where samples 1 and 2 are set in a loop.
Quite a lot of variables involved here along the sequence of actions while playing, so I need to work this out.
My experiences testing the provided file with .42 was that when adding notes with instrument 1 without playing the file while doing that, the notes indeed did remain looping, but at first only two first notes remained and the following ended as expected(?), but at some point the behavior changed so that it seemed that all notes remained looping.
Ok here's what's happening:
. If I open the song, and start playing notes in the pattern editor before playing the song, notes are cut as soon as I let go of the key.
. Pressing play causes some state to change, after which, when releasing a key, the instrument usually stops according to its fade out value. Sam Zen, all instruments in this track have been set to fade out 0, meaning no fade, rather than the default 256. Try setting it to 999, and the instrument will stop when you let of go the key.
There is still a bug here: we should be respecting the fade out value consistently, not intermittently.
2 rewbs
What do you mean by "respecting the fade out value consistently, not intermittently" ?
If concerning fade-out value I notice a 'reverse' order. Zero is infinite while a big number means very short.
In the meantime, while testing this, I'm beginning to find advantages in this behaviour.
Because the changes of the fade out value has direct consequences on the realtime playback, it becomes an
extra, useful, control. By the way : value 999 still has a slight fade-out imo.
Quote from: "Sam_Zen"2 rewbs
What do you mean by "respecting the fade out value consistently, not intermittently" ?
If concerning fade-out value I notice a 'reverse' order. Zero is infinite while a big number means very short.
In the meantime, while testing this, I'm beginning to find advantages in this behaviour.
Because the changes of the fade out value has direct consequences on the realtime playback, it becomes an
extra, useful, control. By the way : value 999 still has a slight fade-out imo.
I usually use 4000 as fadeout value to have and somewhat instant stop. Havent tested what's the upper limit, but I'd guess it's around 10000.
You say it : somewhat. A fade out can be short enough to simulate a sudden stop, but is not the same as a direct stop,
as will happen with these looping samples, if another pattern in the score is directly chosen, or the song is stopped.
During playback the direct switch for this is available in the sample-bar under 'Loop' and 'Type' : Off en On.
This is immediately executed, so also here I pose the question : Could this switch be synced with the transition ?
Quote from: "Sam_Zen"You say it : somewhat. A fade out can be short enough to simulate a sudden stop, but is not the same as a direct stop,
It's usually a good idea to have some fading else you get clicks. Their are probably more fades going on than you think in all sound applications (most have some kind of ramping on stop).
Quote from: "Sam_Zen"This is immediately executed, so also here I pose the question : Could this switch be synced with the transition?
You mean kill all loops for a given instrument on pattern transition, so you could press a key, release it, but the note would keep playing until the end of the pattern?... I guess it could be done, but seems like a bit of an oblique feature to me. I don't want to complicate things (including my schedule :) ) too much with live-specific features, as this isn't OpenMPT's primary purpose.
Quote from: "rewbs"It's usually a good idea to have some fading else you get clicks. There are probably more fades going on than you think in all sound applications (most have some kind of ramping on stop).
Quite right. And elegant programmed apps should have such algoritm.
The first thing to avoid clicks though is still up to the user :
Making sure that a sample starts and ends with a zero-level. Looping or not. A fade out also can have a length of 1 ms.
Quote from: "rewbs"I don't want to complicate things (including my schedule Smile ) too much with live-specific features, as this isn't OpenMPT's primary purpose.
I'm fully aware of the priorities here above live-specific features. OMPT is first of all an editor.
Since OL's player is no longer developed, I can only suggest for those live-features within the editor.
But since e.g. the addition of the change-at-transition-algoritm, I've been able to use my laptop as a musical instrument playing together with other people live, and expand educational impact in courses about tracking.
Anyway. I could declare this topic as 'no longer a bug', because thanks to this discussion and the testing I did, I know now how to handle it, programmed or realtime manually.
Quote from: "Sam_Zen"Anyway. I could declare this topic as 'no longer a bug', because thanks to this discussion and the testing I did, I know now how to handle it, programmed or realtime manually.
Ok thanks. I'm going to keep it open for now cos I think there's still something not quite right.
Nice intuition. I still wasn't able to reconstruct it, but I remember an odd behaviour (not exactly), depending on the 'loop pattern' box being on or off, for example. And I still have to check some thing with the generic version.
Bumping old bug...
Closed this as the original issue was resolved and I can't remember why I wanted to keep it open. :)