deferlow needed in max6, when not needed in max5
Hi, Ive got a patch that works perfectly in max5. However, I tried it in max6 and it now needs a deferlow. I wouldnt mind but its taken quite a long time to determine that a deferlow was needed. Basically, my patch wouldnt work in max6 unless it was opened in the editor (in m4l).
I have to ask, how come max patches behave differently between 5 & 6. Only reason I say this is because ive seen quite a lot of other peoples m4l patches broken due to the introduction of max6. Two that come to mind are the launchpad sequencer by novation and drumseq. Is there anything special we should be doing to avoid this?
Cheers N
Sorry - we can't comment unless we can see your patch - please let's have a look at a stripped down example of what you're seeing.
Cheers
-A
Hi Andrew,
I have pasted the code beneath and shown where the deferlow needed to be added. When I used the device that was saved with Max5 it ran in Max6, but as soon as I opened it and saved it in Max6, it required the deferlow to work. I also had to use another deferlow beneath, because it seemed to not work the same as an audio effect as a midi effect (midi needed 1 deferlow, audio needed 2)
There is another strange problem happening when I set the routings. If I duplicate this device and change the "set current_input_routing" to "set current_output_routing" (so there are two devices, one changing inputs and one outputs), Live crashes. Live doesnt seem to like changing the input and output of the same track at the same time. Id be really grateful for some guidance on the best way to do this. Do you think it might need some delays on the output?
Cheers
N
I'm getting a bunch of
live.object: Invalid syntax
errors loading this.
What's the idea of the device? What's it supposed to do?
-A
I notice that the device uses global s/r messages which introduce unpredictable latency and thus may cause unexpected behavior.
Its for recording loops live by simply selecting a new track. You can change the routing of the currently selected track and reset the routing of the last selected track. Try this:
1) create 4 midi tracks
2) go to the device and put "Computer Keyboard" in the 1st text edit and "Ch. 1" in the 2nd textedit
3) in the 3rd text edit put "No Input" and 4th text edit leave blank
Then select midi tracks 1 2 3 & 4. You will notice that it's sets the currently selected track to computer keyboard and then the track you selected before that will go to no input. You can also arm/disarm and solo/unsolo. Eventually Id like to be able to set different routings for specific tracks.
Broc, it's a good point. Although I did try also with.non global routings ala --- but still encountered the crash
How do global s/r objects introduce unpredictable latency any more than would local s/r objects?
While I can imagine that the order in which events are sent out might change with different implementations (possibly explaining the behavior difference between Max 5 and 6 for the OP), I don't understand how latency is any more unpredictable. (Actually I didn't know latency was predictable at all with those objects)
As I understand it, the problem with global s/r in M4L devices is that sender and receiver may run on different tracks (threads). This requires some buffering scheme which leads to unpredictable latency. In contrast, local s/r (ie. names with prefix ---) are handled the same way as s/r in Max alone.
Ah, thanks for the explanation --- I'm only using Max by itself so wasn't aware that M4L did it differently.