mtr - confusion about touch
Hello, I try to understand how the touch message for [mtr] is working.
While in first place it looks like a quite simple command to overwrite a track there seem to be some limitations that are not that obvious or potentially these are bugs.
The following patch makes use of @bindto.
Questions
a) Can I overwrite tracks while "touch 1" that are assigned via @bindto and have no patch cord connection to [mtr]? Or is it necessary that the inlet of the track in the [mtr] receives the recording data?
b) Can I mix tracks connected via @bindto and tracks connected via patch cords to track inlets?
c) Does the attached patch work as intended? For me it looks totally buggy or inconsistent - not recording correct or at all while touch 1.
MAX 8.1.8 MacOs Catalina
It looks like it's working here, at least, it's working the same whether bound through patchcord or not.
Since touch works only while playing, I can't record with "touch" if nothing is already recorded in the track. But if I already have data in the given track, I can touch it.
Indeed, if a track is empty, I can't record in it with touch. Is that what you're seeing?
What I see e.g. is the following
Record
a)Move red slider up and down during 1s b)Move green slider up and down during 1s b)Move blue slider up and down during 1s c)Move small pale blue slider up and down during 1s
Stop
Play (sliders move as expected)
Activate switch for touch message to red slider (all others prevent mtr receiving touch)
Press space bar -> touch 1 (red slider doesn’t move anymore as expected)
move red slider while still pressing spacebar
release spacebar -> the red slider remains at a constant position, the movement was not recorded
Alternatively sometimes the behaviour is
6. Press space bar -> red slider moves despite touch 1
Edit: Maybe I misunderstand the concept of touch but i expected, that during touch 1 the parameter does not play the recording.
Also the patch above includes looping. It looks like if one has erased all events by touch 1 and it starts the next loop it won't record anything .
Indeed, if a track is empty, I can't record in it with touch. Is that what you're seeing?
Yes this is also confusing.
That might be the expected behavior (not sure!):
- as soon as you say "touch 1", the track is momentarily in record mode, does not play anything, so it's "normal" that on your step 6 above, the red slider is not moving anymore.
- now on your step 7, I'm afraid it depends on how long you had the "touch" active before that: if touch was active long enough to record "nothing" on the whole duration of the track 1, then your track 1 has no data anymore in it. So... it's not playing anymore, and the "touch" message has no effect anymore.
So, maybe the expected use is something more along these lines (this patch really doesn't make sense, but I hope it shows the idea).
The behaviour is very confusing and I think you are right - after clearing all events in a track it won't record because it is not playing anymore.
But still there is sometimes the other behaviour where touch 1 does not affect the slider and the slider keeps playing.
But still there is sometimes the other behaviour where touch 1 does not affect the slider and the slider keeps playing
i got this behavior a couple times, so i decided to run some tests to make sure and i found that if i don't use the exact 'mtr' object in your original patch(i delete one character in the arguments and then retype it causing it to get a fresh new instantiation of 'mtr' but with all the same settings), it doesn't seem to go wrong for me after that(this makes me think maybe there's some attribute or internal setting or maybe some corruption that is specific to the instantiation of the object you posted).
also, not entirely related, but it was confusing me at first that the length is not determined by the length between 'record' and 'stop'(for that type of behavior, i'd need to use "length 0, record" and "definelengthandstop" shown under the 'record' tab of the helpfile), and so at first, i thought 'touch' wasn't working because i expected i'd be able to gauge the timing of my touch-recording by looking at all the sliders in relation to the red-one, but now i understand.
other than that, 'touch' seems to work for me as expected.
if i don't use the exact 'mtr' object in your original patch(i delete one character in the arguments and then retype it causing it to get a fresh new instantiation of 'mtr' but with all the same settings), it doesn't seem to go wrong for me after that(this makes me think maybe there's some attribute or internal setting or maybe some corruption that is specific to the instantiation of the object you posted).
I also suspect something like this, maybe related to the bindto issue reported here
https://cycling74.com/forums/-bug-mtr-bindto-on-patch-startup-causes-problems/replies/1#reply-5f9ed70d6836bb2834fa6f2a
But there is something more to consider. I took the "WhereAmI" sub patcher from Andrew Bensons post https://cycling74.com/feature/mtr in order to see how the tracks are playing.
It seems like if a new loop starts it ignores the touch 1, you have to send it again to take effect. I think this explains some of my observations.
ok.. I just spend too many hours on the mtr system.
But if you observe the dict it becomes clear that "touching" flips to 0 after the end of each loop.
-but, there is also an "end trackNr" message send at the leftmost outlet. So one could use that to reset touching to 1
I think it's also not really practical, live-performance wise, if you have to arm each UI-Object before you overdub. And "De-Arm" the ones you don't want to override. Imo the MTR should just overdub the ones that are moved (which of course doesn't work if you work with the @bindto arguments)
-But if not, there is a nice workaround in the patcher below (also for the first mentioned problem)