I know I spoke about controlling forking/translator hierarchy etc a while back but I realise it might be a simple fix.
Currenly, when you select 'Stop Processing after…" flag, it stops dead at that point. What would be really helpful would be moving that option to the ‘Outgoing’ field eg
A. ‘Stop Processing’
With Options of:
'Stop Processing After This Translator
‘Stop Processing In This Preset’
This way eg when scanning and applying a range of notes to be used, if the incoming event stream does not match range, it would stop at that point, essentially creating an exit at that fork ie it might be an extra translator to filter the beginning of the preset but well worth the hassle; even better if it could be shorthand in the rules window, thereby nipping execution in the bud; I find it an essential tool especially in large projects/optimisation
OR
In other words, the stopping of any further translation should be conditional
Just a thought as its been an ongoing frustration in an otherwise brilliant landscape.
Thanks for the suggestions. I will pass them along.
A few notes
Stop Processing after this translator
This is the current behavior if the translator executes
Stop Processing after this preset
You can trigger a timer and have the first translator of the following preset, monitor for that timer. Then use Stop Processing as above. So the timer will trigger and processing will start at the next translators with the timer.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Here I setup to trap an event which the log confirms, the translator has a “none” output which is executed but the code continues along without stopping? ie after executing the translator with a stop applied
Yes, as I said, I passed your request along. I always like to give real life possible alternatives that you can do now just in case it takes a while for the request to get implemented.
Best regards,
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi @mwesse ,
thank you, from me, too, for these suggestions. If you don’t mind, I’d like to brainstorm a bit about this. Thing is, I’ve never quite liked the “Stop Processing” flag. If it wasn’t for backwards compatibility, I would have removed it a long time ago. Why?
Either, it is merely an optimization, which the engine could/should be able to do on its own (and rarely actually necessary anyway – with today’s CPU’s),
or it is a method for actual logic in the translation project. As such, it is difficult to handle, because it is on such a different level than how logic works in MT Pro in the Incoming section and the Rules section. All other functionality has an immediate effect, like “exit rules, skip outgoing action”. The Stop Processing flag is much less visible, and will not show its effect unless there are multiple translators with the same incoming trigger. Changing the order of presets can have unforeseen effects if Stop Processing is not set with a lot of care. It might lead to other seemingly random problems, contradicting MT Pro’s core strength that its processing is 100% deterministic.
Here at Bome, the second point above also manifests itself in the internal source code of MT Pro: everything is modular, except for this Stop-Processing flag which needs a lot of special case handling to make it work.
Now for the brainstorming. IMHO, it would be better to identify the reasons why you’d like more Stop Processing, and possibly find ways to integrate them in a different way.
Stop Processing In This Preset
Currently, presets only have a limited filtering method by selection of a MIDI port (which still doesn’t prevent processing of other translators). Maybe a Preset could get a filter, e.g. by MIDI channel: “For MIDI messages, only process this preset if the incoming message is on channel 7”, and possibly other filters. And maybe Presets could also get a Rules section, which gets executed when an incoming event is going to be processed by the translators in the preset. Then there could be a rule “Don’t process this preset (skip to the next preset)” for dynamic handling.
Can you think of a way that would suit you and which doesn’t have the “deferring” nature of Stop Processing?
Thanks @FlorianBome for the explanation
I agree, a positive flow with filter is much preferred to negative actions
There are a number of areas this applies to but Ill try and explain a couple
BACKGROUND: Most of my application involves setting up live rigs with a lot of gesturing so that using controllers is a lot more right brain vs left brain, I originally did all this (way back in dev phase, the hardway) in vbscript/midiox and then migrated to pd which was unreliable for startup so I went to max which was not very portable ie they stopped allowing plugin support which mean then each person needed a max install.
I then went back to mtp with a bit of startup help from @SteveC, however, ended up rewriting a lot of stuff; It got ridiculously complex very quickly but after the rewrite it became far more parametric. In the meantime was doing OEM work for music hardware > Live which opened my understanding many fold but all the gesturing was now in hardware and not transportable.
A system developed out of all that whereby it worked really well, amalgamating it all into a spreadsheet and dumping all the data out xml into the various receivers, but now I needed to be able to transplant that back to a portable application like BMT so full circle…hope that wasnt too verbose
So
The way I use it mostly; the presets are created for a module eg a range of note numbers from eg a foot controller and will be exclusive targets of a preset. This has been quite cumbersome because those notes only belong to that preset and ‘Stop Processing’ seemed to be the only optimiser (regardless of cpu )
To me, the gate type of logic in Pure Data was the easiest whereby I could just use compound comparison and anything matching the pattern entered the gate but optionally wasnt passed on any further.
Having that type of device (as you suggested) at the head of the preset makes absolute sense.
Not sure I’m completely following but would something like this work?
Have an “always on” preset with translators that look at the incoming note range and enable a given preset if they are in the range and disable it if not?
IE in the first preset which is checked as always enabled:
Translator 0.1 enables preset 1 only
Translator 0.2 enables preset 2 only
The above is possible now.
If I understand Florian’s idea, it would be to further develop MT Pro to set up a “preset pattern” that only allows a given note range (or perhaps other trigger conditions) to operate on a given preset. This is similar to what we do with using presets for MIDI device selection today by defining targets at the preset level.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Hi Steve
I did try that but, if its ok to be honest…its just verbose when it doesn’t need to be. Each fork adds complexity and really doesnt need all the switching when the condition is the switch
Maybe I have it wrong and have a lot of siltation from that background but simple tree type hierarchy is all that is needed…its natural logic
ie localising the control flow instead of vectors or in other words, embedding the pattern match at the head of the preset keeps the flow encapsulated/modular…tracking dependencies just adds more to the work.
What would be amazing would a graphic front end like PD that could write out xml to a format that the mtp engine could load and use natively…just a pleasant thought.
MTP is just so robust and bootup and consistency
I would like to thank you @FlorianBome for the help earlier this year on getting the xml translation working for the keypad project…that made cubase a rocket…Im not kidding.
In your example, you use exit rules, skip outgoing action.
Like ‘Swallow’ I believe that the stop processing will only happen if the outgoing action is executed.
In your example stop processing should happen if pp<=7 if you have the stop processing flag set for the highlighted translator. I think this might seem counter-intuitive but I’m pretty sure that would work. I’m not at my PC now (I’m on my chromebook) so I haven’t tested it.
I also found this to be a point of confusion in the past.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Sounds good. I just read this from the manual so I’m pretty sure my assumption about stop processing is correct.
Excerpt from Page 36
If this is enabled, successful completion of this translator’s Outgoing Action will cause
the rest of the translators in the current preset, and in following presets, to be ignored.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
I recall seeing non event stuff in the log when i did it that way…but still I think the issue is, the nature of the logic
I need to stop the execution of the preset on non valid events but continue to the next; not really stop everything dead…its sort of like a dirty break from a sub…this “stop” example could of course go at the end of the preset but highlights the issue; the trapping needs to be at the head/entry point.
I’ll play around with it and test a bit. I still think ides of enhancements are good ( so thanks for the dialog!) which of course fits into Florian’s area. I still always like to look for easier ways to do things with the current implementation.
I was just thinking, if you only want a preset to be filtered on a certain condition, then how would we handle timers? Where would set the condition? When timers are used, the preset is active for any timers within that preset if it is active. We might need to have separate conditions for timers within an active preset.
Steve Caldwell
Bome Customer Care
Also available for paid consulting services: bome@sniz.biz
Timers are locally scoped via conditionals for most of it and they are generally only 1 set of timers per preset that run on a singular message, then code out the gesture meanings using bit setting in the val 3 of the message. This gets deciphered by the python/remote script in ableton so that one midi msg carries 7 messages encrypted ie 7 bits Ie else it would quickly run out of note/controllers and be a nightmare to manage…so itsall quite constrained.
Hth
)