'Caution' dropouts and crashes with preset object in M4L!

[Adesso]

During the development of my last MIDI device I experienced huge problems with lags in visualization and audio dropouts. The device is a pure MIDI processor, no Audio, no externals. It uses the preset object in conjunction with the pattrstorage object, working perfectly with Live's Preset and Live Set storage and recall. The audio dropouts did not show up while in MAX device editor but the visualization lags were worse (up to several seconds!)..
I contacted cycling74's and Ableton's support. They replied but couldn't help. Already I had found out that the problem was related to the pattrstorage and related functionality. I particular the audio dropouts happened in coincidence with the store function. In addition the frequency of partial(MAX only) or total crashes increased dramatically up to 1 crash every 15 minutes when using MAX device editor!

Then I decided to replace the preset object by own code (mix of a bpatcher and javascript). I just needed a personalized behavior respect to the original preset object.

And – magically – all above mentioned problems disappeared! Also the frequent crashes using the MAX device editor are (nearly 99%) gone.
As seasoned programmer I'm used to proceed in an incremental manner - 1 modification at a time – and test. So introducing the new preset management nothing else had been changed. That's why I'm absolutely sure that the culprit was the preset object!
Hope this may be helpful for someone...

Jürgen

- the device:
http://cycling74.com/project/euclidean- ... generator/

[broc]

Maybe the problem is caused by overload of Live's undo history?

[Adesso]

Maybe the problem is caused by overload of Live's undo history?

Don't think so, because undo is working flawlessly with and without the preset object. And, the number of stored ui objects managed by life has not changed.

[Adesso]

The first thing coming to my mind is: why would you want to use the preset object in M4l in the first place?

Normally Live itself will take care of presets; its also why you'd want to use Live objects in a M4l patch so that their settings can be stored; either in the liveset itself or as a single preset. This also makes it easier on the end user because they can use the patch just like any other Live devices. Well; apart from the option to collapse & expand the device and its presets I suppose

Even so; if they want to use a specific preset they can drag it in straight from the browser instead of first loading the device and only then being able to select the preset they want.


I've only experimented a little with preset myself, but I can't help wonder if the actual cause of your problems doesn't lie elsewhere. Quite frankly I can't reproduce any specific audible problems when messing with preset in combination with pattr.

Do you have any concepts of proof which demonstrate this behaviour ?

My device is using Live presets of course and fully compatible with Live Sets, drag and drop, undo... like any other well made patch!!!

The presets I'm talking about are sub-settings (Variations) and as such are contained in the Live Presets. My Device is a Poly-Rhythmgenerator. Each rhythm can contain up to 12 Variations(left side in the image) which are triggerable by MIDI note in real-time. So each rhythm is a Live Preset, each variation a sub-setting managed by MAX's pattr mechanism.


The audio dropouts are happening in certain conditions (in my case: ASIO4ALL / external USB A/D converter), reproducible at 100%. The visualization/functional lag is always present. Stripping down my patch to an extremely simple one - preset controlling pattrstorage with some UI object - the problems do not show up. But my device is obviously much more complex.

Proof of concept: Introducing the new preset management nothing else had been changed! And the problem disapeared. Rolling back to the old aproach it is there again.

Of course I researched very much in detail, in order to discover possible side effects/reasons. I disabled single sections of the patch one by one without result. Only substituting the preset object solved.