thank you for fixing the issue regarding proper drawing of event graph.
But there is a similar issue.
When jumping around with the playback marker and starting playback,
the midi controller levels are (still) set according the midi events received lastly.
But typically you want to hear your music as if it would be played from start of composition.
This means, when hitting playback at a random position, then first of all for all tracks each midi event (for each cc type except notes)at rightmost position left from playback position should be sent to have some kind of proper initialization.
Do you think this might be a good solution ?
cc levels shown in editor not always what you hear
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
MU.LAB does exactly that.
I've quickly re-checked 2.6.2 on this aspect and it works ok.
Note that muted tracks/parts this are not scanned, of course.
Can you please give more details of when/where it does not work as expected?
I've quickly re-checked 2.6.2 on this aspect and it works ok.
Note that muted tracks/parts this are not scanned, of course.
Can you please give more details of when/where it does not work as expected?
-
- KVRist
- Topic Starter
- 152 posts since 15 May, 2009 from Germany
Hello Jo,
yes, confirmed, a quick check shows, that MU.LAB works fine, as expected.
But under following condition it does not:
If there is no left hand event, then the last event is still valid.
In this case I would prefer to have a default value (e.g. no de-tune coming from last pitch bend event).
Two more special cases I found now, which does not work as desired:
1) As you wrote, MU.LAB scans for the right most events left from current position, but it also accepts events left from START position of current sequence, this is overdone.
2) Ignoring muted tracks is ok, but I think scanning and re-initializing is done immediately after re-positioning of playback marker. But this should be done again when pressing PLAY, because meanwhile you might have unmuted a track.
Hope this clarifies this issue.
Things might be more complicated when trying to find the relevant right most event when considering all tracks, sequences and cc sources (or does MU.LAB "simply" goes from left to rigth to current playback position and sending all events, means some kind of quick and silent playback simulation ?)
yes, confirmed, a quick check shows, that MU.LAB works fine, as expected.
But under following condition it does not:
If there is no left hand event, then the last event is still valid.
In this case I would prefer to have a default value (e.g. no de-tune coming from last pitch bend event).
Two more special cases I found now, which does not work as desired:
1) As you wrote, MU.LAB scans for the right most events left from current position, but it also accepts events left from START position of current sequence, this is overdone.
2) Ignoring muted tracks is ok, but I think scanning and re-initializing is done immediately after re-positioning of playback marker. But this should be done again when pressing PLAY, because meanwhile you might have unmuted a track.
Hope this clarifies this issue.
Things might be more complicated when trying to find the relevant right most event when considering all tracks, sequences and cc sources (or does MU.LAB "simply" goes from left to rigth to current playback position and sending all events, means some kind of quick and silent playback simulation ?)
Everything should be made as simple as possible, but not simpler!
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Ah, good point indeed.Eggu wrote: If there is no left hand event, then the last event is still valid.
In this case I would prefer to have a default value (e.g. no de-tune coming from last pitch bend event).
Added a note to the M3 whishlist.
I don't agree.Two more special cases I found now, which does not work as desired:
1) As you wrote, MU.LAB scans for the right most events left from current position, but it also accepts events left from START position of current sequence, this is overdone.
I agree with you in your first mail: It should be like you played the composition from the start.
Right?
I do want the scan to occur when you reposition.2) Ignoring muted tracks is ok, but I think scanning and re-initializing is done immediately after re-positioning of playback marker. But this should be done again when pressing PLAY, because meanwhile you might have unmuted a track.
Again for the same reason as above. It's the most natural way, imho.
When a track/part is unmuted afterwards, i recommend to just reposition on the same position.
Without going too technical, MU.LAB takes everything into account.Hope this clarifies this issue.
Things might be more complicated when trying to find the relevant right most event when considering all tracks, sequences and cc sources (or does MU.LAB "simply" goes from left to rigth to current playback position and sending all events, means some kind of quick and silent playback simulation ?)
I 100% agree with the principle: The situation at the new position should be the same as if you played from 1.1.0000 to that new position.
-
- KVRist
- Topic Starter
- 152 posts since 15 May, 2009 from Germany
Yes, your last statement summarizes all the special cases.
But let me explain again the point "left from START".
To be more precise: Do not consider events left from START marker AND left from LOOP marker ... because also when playback from song start these events would be fired never (might be other part with same sequence but different markers make these events become relevant in this other copy).
But let me explain again the point "left from START".
To be more precise: Do not consider events left from START marker AND left from LOOP marker ... because also when playback from song start these events would be fired never (might be other part with same sequence but different markers make these events become relevant in this other copy).
Everything should be made as simple as possible, but not simpler!
-
- KVRist
- Topic Starter
- 152 posts since 15 May, 2009 from Germany
Again, to be more precise.
What I want to say:
Don't consider midi events which might be located in the dead midi stuff that might occur at the beginning of a part,
like in this example:
For sure, there might be other parts left from current position which must be scanned.
Sorry for complicated explanation, but as I analyzed, currently also events in a dead part are considered.
What I want to say:
Don't consider midi events which might be located in the dead midi stuff that might occur at the beginning of a part,
like in this example:
For sure, there might be other parts left from current position which must be scanned.
Sorry for complicated explanation, but as I analyzed, currently also events in a dead part are considered.
Everything should be made as simple as possible, but not simpler!
-
- KVRAF
- 1706 posts since 22 Apr, 2009 from Belgrade
i found the same problem in mulab a while ago, but thought it was discovered and going to be fixed in M3. anyway, Eggu explained it well, but here's just another explanation:
if we draw a sequence of 8 notes marked with (=) and automate for example the filter cutoff frequency marked with corresponding value numbers (1,3,6,...), we would get this:
= = = = = = = =
1 3 6 7 8 9 8 4
which is good. but, if we play the sequence until the fifth note for example, and then press stop, the filter cutoff remains at the value of 8. so, if we then click some other part of the song where the cutoff isn't automatically controlled, the filter cutoff will play at the value of 8 instead of resetting to a value used before the automation sequence which would be more logical.
if we draw a sequence of 8 notes marked with (=) and automate for example the filter cutoff frequency marked with corresponding value numbers (1,3,6,...), we would get this:
= = = = = = = =
1 3 6 7 8 9 8 4
which is good. but, if we play the sequence until the fifth note for example, and then press stop, the filter cutoff remains at the value of 8. so, if we then click some other part of the song where the cutoff isn't automatically controlled, the filter cutoff will play at the value of 8 instead of resetting to a value used before the automation sequence which would be more logical.
Bedroom Producers Blog << Free VST Plugins!
-
- KVRist
- Topic Starter
- 152 posts since 15 May, 2009 from Germany
OOps, all clear regarding my last stated issue.
Checked again with a more simple example.
Seems that Mulab does well and does not consider events in "dead" sequence parts.
Remains the wish to have some default initial values.
Checked again with a more simple example.
Seems that Mulab does well and does not consider events in "dead" sequence parts.
Remains the wish to have some default initial values.
Everything should be made as simple as possible, but not simpler!
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
@Eggu:
Thanks for all info.
Based on your last message i understand there is no problem, right?
Only a FR to use a default value for controllers/parameters if (and only if) there is no relevant event before the new position.
Right?
@ bedroomproducers: Do you agree with this analysis.
Or are you convinced there is an issue? If yes, please elaborate.
Thanks!
Thanks for all info.
Based on your last message i understand there is no problem, right?
Only a FR to use a default value for controllers/parameters if (and only if) there is no relevant event before the new position.
Right?
@ bedroomproducers: Do you agree with this analysis.
Or are you convinced there is an issue? If yes, please elaborate.
Thanks!
-
- KVRAF
- 1706 posts since 22 Apr, 2009 from Belgrade
if FR means feature request, then yes, i aggree.mutools wrote:Only a FR to use a default value for controllers/parameters if (and only if) there is no relevant event before the new position.
it still is a bit complex, though. should the "default" setting be the setting before or at the very end of the automation sequence?
for example, my filter cutoff is set at 5 at the begining of the song. after eight bars comes a four bars long automation sequence which drives the cutoff slowly from 7 to 9. so at the second bar of the automation sequence, the cutoff is set to 8 and growing.
now, in current state uf mulab, if i:
- 1) jumped during the second bar of the automation sequence to some other place further in the song, the cutoff would be set to 8. i think this isn't good... the cutoff should be automatically set to 9.
2) jumped during the second bar of the automation sequence to the second bar of the song (before any automation happened), the cutoff will again be set to 8, but in this case it should be automatically set to 5.
Bedroom Producers Blog << Free VST Plugins!
-
- KVRist
- Topic Starter
- 152 posts since 15 May, 2009 from Germany
bedroomproducers wrote:
2nd case is "the old issue" that there is no initial event, how to solve ?
Should mulab memorize the initial value of each controller at program launch (e.g. cutoff) and use this as first dummy event later on?
Look at this further example, where I've recorded 3 master volume changes at bar 2, ~3.5 and 5:
Everything works as expected when jumping around between bar 2 and 6.
No automatic volume change will happen when jumping left of bar 2,
because there are no volume events in this region.
Now look at the copy beginning at bar 6, but with re-positioned start marker one bar to the right.
--> initial events now masked and not considered !
When looping, this now has the effect, that at bar 9 there seems to be a volume event, it's only a fake, because this step results as a picture copy of the sequence and represents the level also seen at bar ~3.
When jumping to position 9.x as shown, the volume slider is set automatically to the level from the last event, and this event happens at position ~8.8, which is lower than the fake plateau at current cursor position.
... this will work fine as expected, when I try similar examples.1) jumped during the second bar of the automation sequence to some other place further in the song, the cutoff would be set to 8. i think this isn't good... the cutoff should be automatically set to 9.
2nd case is "the old issue" that there is no initial event, how to solve ?
Should mulab memorize the initial value of each controller at program launch (e.g. cutoff) and use this as first dummy event later on?
Look at this further example, where I've recorded 3 master volume changes at bar 2, ~3.5 and 5:
Everything works as expected when jumping around between bar 2 and 6.
No automatic volume change will happen when jumping left of bar 2,
because there are no volume events in this region.
Now look at the copy beginning at bar 6, but with re-positioned start marker one bar to the right.
--> initial events now masked and not considered !
When looping, this now has the effect, that at bar 9 there seems to be a volume event, it's only a fake, because this step results as a picture copy of the sequence and represents the level also seen at bar ~3.
When jumping to position 9.x as shown, the volume slider is set automatically to the level from the last event, and this event happens at position ~8.8, which is lower than the fake plateau at current cursor position.
Everything should be made as simple as possible, but not simpler!
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Indeed it doesbedroomproducers wrote:if FR means feature requestmutools wrote:Only a FR to use a default value for controllers/parameters if (and only if) there is no relevant event before the new position.
The default would only be used if there is absolutely no relevant event before the new position, in whatever part.should the "default" setting be the setting before or at the very end of the automation sequence?
The default for pitchbend = center.
The default for controllers = cfr Reset All Controllers cfr http://www.midi.org/techspecs/rp15.php
Anyway, it's not yet planned to add such default behaviour on the short term as i've got to think this thru a bit more.
The recommended thing to do is to explicitly add initialization events at the start of your composition, like it is done in the Demo.MuSession.
Well, in this case there is no further issue.for example, my filter cutoff is set at 5 at the begining of the song.
Wherever you'll put the position, MU.LAB will always find an event at the left of the song position.
Oh, in fact, now that i think of it, there is an issue:
When placing the position at the very start, the relevant values will only be sent out when starting playback.
So that's something i'll add to the whishlist: When placing the position at 1.1.0000, any relevant events at 1.1.0000 should immediately be sent out.
So the automation sequence goes from 9.1.0000 to 13.1.0000.after eight bars comes a four bars long automation sequence which drives the cutoff slowly from 7 to 9. so at the second bar of the automation sequence, the cutoff is set to 8 and growing.
Cutoff goes from 7 to 9.
So at 10.1.0000, cutoff will be at 7.5.
Maybe i misunderstood your example?
Sure, if you jump past 13.1.0000, cutoff should be set at 9. Isn't it?1) jumped during the second bar of the automation sequence to some other place further in the song, the cutoff would be set to 8. i think this isn't good... the cutoff should be automatically set to 9.
Indeed. Isn't it?2) jumped during the second bar of the automation sequence to the second bar of the song (before any automation happened), the cutoff will again be set to 8, but in this case it should be automatically set to 5.
Feel free to publish a simple MuSession that demonstrates a problem.
-
- KVRAF
- 13863 posts since 24 Jun, 2008 from Europe
Ah, right, i see.Eggu wrote:When looping, this now has the effect, that at bar 9 there seems to be a volume event, it's only a fake, because this step results as a picture copy of the sequence and represents the level also seen at bar ~3.
When jumping to position 9.x as shown, the volume slider is set automatically to the level from the last event, and this event happens at position ~8.8, which is lower than the fake plateau at current cursor position.
Added a note on the whishlist!
Thanks!
-
- KVRAF
- 1706 posts since 22 Apr, 2009 from Belgrade
omg, i was so competely and utterly wrong! 
my excuses go to both of you from me for typing all this rubbish info in my previous few posts. i have just tested the automation and it works exactly how i thought it doesn't.
on a positive note, now i know that i should always define a default value at the begining for all the plugins that i plan on automating. thanks! tougher way of learning though, eh?
my excuses go to both of you from me for typing all this rubbish info in my previous few posts. i have just tested the automation and it works exactly how i thought it doesn't.
on a positive note, now i know that i should always define a default value at the begining for all the plugins that i plan on automating. thanks! tougher way of learning though, eh?
Bedroom Producers Blog << Free VST Plugins!