Optimization questions

TomViolenz

2015-12-06 12:43:27

Hey guys :-)

Here is a very satisfied customer, whose Bomes templates reach a level where the Midi processing seems to get a bit flaky at times. I'm running two different instances of Bomes MT Pro at the same time, each with several presets and hundreds of translators. Controlling 7 (soon 8 ) different controller. So this might be expected. Nonetheless I would like to know of some optimization strategies to make my Live set more reliable.

1: First thing I'm wondering is, if I'm really profiting from running two instances at the same time, which I assumed spreads out the processing better and makes Bomes indirectly a multicore application. But, since this set-up causes its own set of problems by doubling the existing Bomes Midi ports of the same name and adding a "2" after it, which does confuse Ableton Live at times, I would prefer not to do this further, if it doesn't benefit me.
(And as a slight add on question, would using port aliases get rid of this problem of Live confusing the ports? I somehow never quite understood their purpose)

2: Secondly, two of my controllers are 64 buttons matrixes (APC Minis), and programming these buttons to do what I want uses up LOTS of translators, which if I understand correctly slows down processing quite a bit. I could conceivably subsume a few of these by filtering the incoming Midi in each translator, which would more or less half the translator count in one preset from 150 to about 80. Would this make enough of a difference to make this rewriting effort worth the while? Especially considering that only a third of these translators actually receive Midi. (While the others get triggered as a result via timers).
So I'm basically wondering if the impact of the filtering, writing the CC numbers to variables, so that the one-shot timers know what CC needs to be processed etc. and the rather complicated translators I would get using "Goto-->Label" combinations, would still be less than having more (albeit simpler) translators.

3: I have one preset which I assume slows down the general processing quite a bit, since it constantly has to process Midi coming from a Midi envelope in a running clip in Live, filter it and start timers and then output Midi based on the resulting calculations. (This is the preset that I mostly run in the second instance of Bomes, so that it does not interfere with the functions of the rest of the translators). Is this something that could really bring Bomes to its knees, or am I being overly cautious? (I'm running this on a Quad Core i7 MBPro)

Any input to stabilize this set up would be greatly appreciated :-)


One more, unrelated question: Is proper undo in the cards for Bomes? I can't count the number of times anymore that I lost lots of work, because of a stupid mistake or a fat finger, that I couldn't revert.

florian

2015-12-09 02:55:40

Hi Tom,
sorry for the late reply. Indeed, your setup is unusually complex, but MT Pro should nonetheless work fine there.

1) Using multiple instances is OK, and indeed, it'll probably make slightly better use of multiple processor cores. But MT's engine is multi threaded, already: all MIDI ports run on different threads, and other actions run on their own threads, too. So if you can, it's probably worthwhile to merge everything into one MT instance. Just make sure that you have a separate set of global variables when merging.

Aliases are strictly internal to MT Pro, so they won't help with Ableton confusion... Here is a description of Aliases: The Beauty of MIDI Port Aliases

2) From my gut feeling, it's not worth it. Translators are very fast, and I've seen projects for controllers with thousands of presets(!), each with tens or hundreds of translators and many many rules -- and it still worked without noticeable delay.

3) again, it's rather unlikely that a preset like that interferes with other translators. The only times where I have seen something like that is a bug in the preset logic (infinite loops, feedbacks, etc.). Check task manager/Activity Monitor for how much CPU each instance of MT Pro uses right now.

To leverage multi core processing, know that each MIDI IN port runs in an own thread, and all the rules and outgoing actions are processed within the incoming action's MIDI IN thread. All timers run in one separate thread, and delayed actions run in yet another thread (but only one for all delayed actions).

For some other information on multi-core processing, see chapter 12.3 in the user's manual. For other optimization techniques, see chapter 13.

Regarding Undo, we hear you. Unfortunately, it's rather complex to add to MT. At least, the Rules text editor has Undo via Ctrl-Z/Cmd-Z keyboard shortcuts (and Redo with -Y). Frequent saving and "saving as" a new name is at least a work-around which I use when working on complex projects.

Please keep us posted with your findings and questions!
Thanks,
Florian

TomViolenz

2016-09-29 17:38:34

Aw, sorry I totally forgot about this thread, but I see I'm back with a similar problem see here: http://www.bome.com/forums/viewtopic.ph ... 147#p24147

Thanks anyways for the detailed answer all these month ago :oops: