Oni Shogun

I have been working with Max for the past two years building various different apps to hijack and control the MIDI communication between my controllers and Ableton Live. The concept is based on the User Mode of controllers which allows for customization of all types of parameter control and M4L access and works incredibly well.

The issue which kept challenging me is the increasing time it takes for the apps/patches to load and I assume it has to do with the following:

• extensive use of bpatcher and/or poly~ objects to allow customization of all knobs/encoders/buttons/sliders on all controllers

• the individual pattr objects for every little setting of every control

• use of fpic and pictctrl to design an organic and less technical GUI, though questionable

However, I am not sure about this and would love some information regarding the issue.

Furthermore, I don't really see any other way of maintaining a flexible customization of settings for every control without the use of poly~, letalone bpatchers (the latter make it a lot more comfortable).

I am prepared to revise all my apps and create a new and reduced one for all controllers which I use live , but I lack a solid approach as to how this can be done technically, especially with regards to reducing the time it takes to load up (currently up to several minutes).

MIDI Controller —> Max (process MIDI as per desired settings) —> App Output/IAC-Bus —> Ableton

Ex.: make a toggle button behave as momentary for switching devices on/off

Ex.: use a button to reset values of encoders (i.e. device parameters) or behave as shift- or 2nd function buttons

Ableton Feedback —> App Input/IAC-Bus —> Max (display of values according to desired style or current mode) —> MIDI Controller

Ex.: make an activated filter device display as a red LED as opposed to a factory green (127 velocity), and yellow when off as opposed to (0 velocity)

these settings are handled by pattrstorage presets according to the current Ableton Live set (udp communication) and change when the set changes.

If anyone has the faintest idea of how I can reduce and improve the loading time and performance of such a nested app I would love to hear about it — at the moment I am staring at my Livid Code and wandering »what the HECK am I supposed to do with your beauty!?«

The Livid Code controller for instance provides four banks and hence requires four bpatchers with abstractions representing the 45 buttons and 32 encoders each — all with numerous pattr objects storing their individual functions and MIDI tools. Would it make more sense to reduce the pattr objects inasmuch as one representing a specific setting for all 77 controls on a bank?

Hi everyone,
I have been working with Max for the past two years building various different apps to hijack and control the MIDI communication between my controllers and Ableton Live. The concept is based on the User Mode of controllers which allows for customization of all types of parameter control and M4L access and works incredibly well.

The issue which kept challenging me is the increasing time it takes for the apps/patches to load and I assume it has to do with the following:
• extensive use of bpatcher and/or poly~ objects to allow customization of all knobs/encoders/buttons/sliders on all controllers
• the individual pattr objects for every little setting of every control
• use of fpic and pictctrl to design an organic and less technical GUI, though questionable

However, I am not sure about this and would love some information regarding the issue.
Furthermore, I don't really see any other way of maintaining a flexible customization of settings for every control without the use of poly~, letalone bpatchers (the latter make it a lot more comfortable).

Remote Control:
MIDI Controller —> Max (process MIDI as per desired settings) —> App Output/IAC-Bus —> Ableton
Ex.: make a toggle button behave as momentary for switching devices on/off
Ex.: use a button to reset values of encoders (i.e. device parameters) or behave as shift- or 2nd function buttons

Ableton Feedback —> App Input/IAC-Bus —> Max (display of values according to desired style or current mode) —> MIDI Controller
Ex.: make an activated filter device display as a red LED as opposed to a factory green (127 velocity), and yellow when off as opposed to  (0 velocity)

If anyone has the faintest idea of how I can reduce and improve the loading time and performance of such a nested app I would love to hear about it — at the moment I am staring at my Livid Code and wandering »what the HECK am I supposed to do with your beauty!?«
The Livid Code controller for instance provides four banks and hence requires four bpatchers with abstractions representing the 45 buttons and 32 encoders each — all with numerous pattr objects storing their individual functions and MIDI tools. Would it make more sense to reduce the pattr objects inasmuch as one representing a specific setting for all 77 controls on a bank?

Am I even being clear enough?
Thank you VERY MUCH in advance!

improve-loading-time-of-patchesprograms

I would actually think of scripting for this and a very very stripped back interface. I am thinking of revising my own applications at some point to use scripting to dynamically create what you need as you need it. It could be fairly complex but would mean you aren't using anything you do not need.

I would actually think of scripting for this and a very very stripped back interface.  I am thinking of revising my own applications at some point to use scripting  to dynamically create what you need as you need it. It could be fairly complex but would mean you aren't using anything you do not need.


I had the same kind of problem with a mega patch full of duplicates bpatchers, each with a lot of pattr.

I noticed that each pattr took a huge amout of memory.

first bang and collects all the actual values in 1 bpatcher, stringify them

and store the 1 string into 1 pattr which is then stored in pattrstorage.

when recalling a preset/pattr it destringify it and route it to each values.

But you loose the capacity of recalling individual values, interpolate them...

and eventually you have to organise your banging sequence to store some values before others.

I noticed a HUGE drop in memory with this 'packing' logic. But not so much in loading times ...

I also noticed that it took much less CPU, given that permanently passing changing values through pattr costs a lot of cpu.

Pattr is great but seems too much ... in term of memory and cpu cycles.

I think it's a recurent problem that avanced maxers find when making mega patches.

I think cycling never answered on this, because certainly it's inherent to the max graphic architecture.

Going back to this packing pattr logic, I use it only for duplicated big bpatchers.

PS: i dont know where it comes from, perhaps conversion from max6 to 7 of some of my patches but copying and pasting some objects in a text editor gave me 30000 lines of codes instead of standart 26.

with a huge ammount of duplicated styles.

I had the same kind of problem with a mega patch full of duplicates bpatchers, each with a lot of pattr.
I noticed that each pattr took a huge amout of memory.
What i did is to make a sytem that :
first bang and collects all the actual values in 1 bpatcher, stringify them
 and store the 1 string into 1 pattr which is then stored in pattrstorage.

when recalling a preset/pattr it destringify it and route it to each values.
But you loose the capacity of recalling individual values, interpolate them...
and eventually you have to organise your banging sequence to store some values before others.

I noticed a HUGE drop in memory with this 'packing' logic. But not so much in loading times ...
I also noticed that it took much less CPU, given that permanently passing  changing values through pattr costs a lot of cpu.

I think it's a recurent problem that avanced maxers find when making mega patches.
huge memory, cpu and loading times.
I think cycling never answered on this, because certainly it's inherent to the max graphic architecture.

Going back to this packing pattr logic, I use it only for duplicated big bpatchers.
Seems to be your case.

PS: i dont know where it comes from, perhaps conversion from max6 to 7 of some of my patches but copying and pasting some objects in a text editor gave me 30000 lines of codes instead of standart 26.
with a huge ammount of duplicated styles.


you are right about subpatchers, bpatchers, poly instances and picture files as one possible reason for long load times.

but from what i can see in your screenshot you are using like 100 or so picture sliders. this should not take longer than 5 seconds to load on any computer with 200 or more MHz. on a modern computer you should see anything like "load time" at all.

so my guess would be that there is something else what causes this here.

but from what i can see in your screenshot you are using like 100 or so picture sliders.  this should not take longer than 5 seconds to load on any computer with 200 or more MHz. on a modern computer you should see anything like "load time" at all.

so my guess would be that there is something else what causes this here.


thank you all for sharing your experience and advice.

meanwhile I redisgned the programs for two of my controllers and the loading time has been heavily reduced.

my previous picture may have suggested that i have used many pictsliders, though in fact they were normal max 6 dials (no longer available) with fpics on top of them as well as bg picture files and the like. as of the new versions, following aspects require a decent loading loading time worth the wait:

• using poly~ instances instead of bpatchers

• only one pattr object in each poly~ instance (saving data of a »function« object)

• all other preset data stored in arrays of pattrs for all controls (interpolation between presets not necessary when mapping ints/bools)

• most of these represent sysex messages, hence their order can be scheduled smoothly

• gui is limited to almost nothing, as for all settings can now be modified from the hardware unit without the screen

• refereces for settings menus are created using scripting (coll/pattrhub etc.)

+ quick loading time and little cpu usage

- (interpolation hardly possible, though not required in my case)

I will certainly avoid using too many — if any — bpatchers, especially containing various pattr objects from now on while using the MIDI controller to manage your settings is more convenient, practical, quick and intuitive than an attractive gui on the screen.

okay,
thank you all for sharing your experience and advice.
meanwhile I redisgned the programs for two of my controllers and the loading time has been heavily reduced.
my previous picture may have suggested that i have used many pictsliders, though in fact they were normal max 6 dials (no longer available) with fpics on top of them as well as bg picture files and the like. as of the new versions, following aspects require a decent loading loading time worth the wait:

• using poly~ instances instead of bpatchers
• only one pattr object in each poly~ instance (saving data of a »function« object)
• all other preset data stored in arrays of pattrs for all controls (interpolation between presets not necessary when mapping ints/bools)
• most of these represent sysex messages, hence their order can be scheduled smoothly
• gui is limited to almost nothing, as for all settings can now be modified from the hardware unit without the screen
• refereces for settings menus are created using scripting (coll/pattrhub etc.)

+ quick loading time and little cpu usage
- (interpolation hardly possible, though not required in my case)

so far so good, it looks promising.
I will certainly avoid using too many — if any — bpatchers, especially containing various pattr objects from now on while using the MIDI controller to manage your settings is more convenient, practical, quick and intuitive than an attractive gui on the screen.

Improve loading time of patches/programs