.41 Request for unloop

Started by Sam_Zen, April 06, 2006, 04:08:07

Previous topic - Next topic

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,
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 ?
0.618033988

rewbs

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.

Sam_Zen

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.
0.618033988

rewbs

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.

Sam_Zen

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.
0.618033988

LPChip

"Heh, maybe I should've joined the compo only because it would've meant I wouldn't have had to worry about a damn EQ or compressor for a change. " - Atlantis
"yes.. I think in this case it was wishful thinking: MPT is makng my life hard so it must be wrong" - Rewbs

rewbs

Closed this as the original issue was resolved and I can't remember why I wanted to keep it open. :)