deferlow needed in max6, when not needed in max5

Apr 4, 2013 at 4:53pm

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

#67535
Apr 4, 2013 at 5:16pm

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

#243005
Apr 4, 2013 at 8:36pm

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)

– Pasted Max Patch, click to expand. –

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

#243006
Apr 4, 2013 at 9:43pm

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

#243007
Apr 4, 2013 at 10:57pm

I notice that the device uses global s/r messages which introduce unpredictable latency and thus may cause unexpected behavior.

#243008
Apr 5, 2013 at 2:22am

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

#243009
Apr 6, 2013 at 6:47pm

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)

#243010
Apr 6, 2013 at 7:23pm

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.

#243011
Apr 6, 2013 at 7:42pm

Ah, thanks for the explanation — I’m only using Max by itself so wasn’t aware that M4L did it differently.

#243012

You must be logged in to reply to this topic.