Andy Maskell

I'm going through the gigantic project that I have been writing for the past year and changing some things to make use of tips and techniques that I have learnt from reading the forums.

And it leads me to a conundrum that crops up in most parts of my project...

As most of my project involves manipulating MIDI messages, there are a lot of occasions where I need to force the output of an integer number following on from the previous event. For example, pressing a button or moving a control on my control desk requires the output of a specific note number. So far, I've encountered three different methods, as shown below:

image.png

 here - it's just a quick example of something that will output a variety of different message types that are 

 most of the time up until now, partly because that was the method used by the guy who wrote the patch that my project is based on and partly because it helped me to understand the logic and partly to be able to follow where my numerous commands were going!

However, as I have become more confident about how Max works, I can see that using two steps is not as efficient as one and using 

 buttons obviously has an impact on display updates. I'm beginning to think that method 

 - Which method do you tend to use and why? Which do you think is the most efficient? Are there any other methods you know of?

I realise that there are always different ways of doing things but this represents the biggest chunk of what my project has to do (there are well over 860 different processes to contend with) so I'm looking for efficiency savings, in space, processing time and reliability.

I'm going through the gigantic project that I have been writing for the past year and changing some things  to make use of tips and techniques that I have learnt from reading the forums.

As most of my project involves manipulating MIDI messages, there are a lot of occasions where I need to force the output of an integer number following on from the previous event. For example, pressing a  button or moving a control on my control desk requires the output of a specific note number. So far, I've encountered three different methods, as shown below:

Ignore the fact that I've chosen unjoin here - it's just a quick example of something that will output a variety of different message types that are NOT a bang.

I have been using method 1 most of the time up until now, partly because that was the method used by the guy who wrote the patch that my project is based on and partly because it helped me to understand the logic and partly to be able to follow where my numerous commands were going!

However, as I have become more confident about how Max works, I can see that using two steps is not as efficient as one and using bang buttons obviously has an impact on display updates. I'm beginning to think that method 3 is best unless I need to use a trigger for an additional purpose.

My question is - Which method do you tend to use and why? Which do you think is the most efficient? Are there any other methods you know of?

I realise that there are always different ways of doing things but this represents the biggest chunk of what my project has to do  (there are well over 860 different processes to contend with) so I'm looking for efficiency savings, in space, processing time and reliability.

I'm going through the gigantic project that I have been writing for the past year and changing some things  to make use of tips and techniqu

a-question-of-numbers

this is a classic patch made long ago by Chris Muir, known as 'Benchmark Timer'(@Cycling74, a suggestion/request that you include this in the 'Examples' folder, perhaps under 'Utilities' or 'Max Tricks'), it can help you determine what event-rate methods work fastest:

when i try your options in the patch like so, i get results that point to using just the integer object by itself(that is, if there was some way you could get rid of the bang above it), otherwise the trigger object is 2nd best, and using message is the slowest:

(but i use message often anyways, because i'm always using it as a quick debugger/display when i construct patches, and i rarely run into any CPU usage issues where i need to get strict about event-rate stuff(i enjoy DSP too much), plus when i alter the value using the right-inlet, it displays the new value, so i can keep track visually, etc... just an all-around convenience/ease preference for me... not meant as advice but more like an encouragement that sometimes whichever solution makes you 'feel' most relaxed, ends up being the most 'humanely-efficient' 😂)

^i'm probably not understanding the full implementation of what you're going for(how does it depend on the previous event? is there an integer '99' involved in the previous event? if so, you could use 'routepass'...) but 'sel' connected to trigger objects is one of my favs, too.

^you might already know this, but just want to add: if the 'bang' is embedded in a subpatcher where it isn't displayed(i.e. hidden from view), it will not impact display updates(although there is still a bit of inefficient calculation to trigger it compared to 'trigger'/'t')

[EDIT: oh! there's also the (hilarious/somewhat-superfluous) [bangbang 1] option, too, in case you really need a bang but want something slightly more efficient than the UI version 'button':

Screen Shot 2022-04-01 at 10.06.07 AM.png

tl;dr - use the 'Benchmark Timer' patch to see which one is the most CPU efficient, but if you're not desperate to save on CPU, feel free to go with the one that feels most convenient for your style of working 🍻

...Are there any other methods you know of?.... where I need to force the selection of a number depending on some previous event...

using bang buttons obviously has an impact on display updates

[EDIT: oh! there's also the (hilarious/somewhat-superfluous) [bangbang 1] option, too, in case you really need a bang but want something slightly more efficient than the UI version 'button':


Thanks. That's all very helpful. The idea of using the right inlet for 

By "forcing" a value, what I mean is that, whatever the incoming message or message type might be, the outgoing message is ALWAYS the desired integer number.

Thanks. That's all very helpful. The idea of using the right inlet for message is always handy.

i´ve always aksed this myself, too. but not because of [button]... more because of [t b].


re:bangbang

i´ve always aksed this myself, too. but not because of [button]... more because of [t b].


I've gone through my project (it's taken all day!) and replaced all the method 1 items (

 box) with a mixture of method 3 (number in a 

 for a specific note to illuminate a button light) with simple messages. It also gave me an opportunity to edit a lot of over-complicated routines and make them more efficient. Getting rid of all those redundant 

 objects has made a big difference. I have to say everything is running much faster and smoother now!

I've gone through my project (it's taken all day!) and replaced all the method 1 items (bang button -> number in an object box) with a mixture of method 3 (number in a message) and method 2 (trigger) I've also replaced a lot of pack objects with static (fixed) values (eg pack 40 127 for a specific note to illuminate a button light) with simple messages. It also gave me an opportunity to edit a lot of over-complicated routines and make them more efficient. Getting rid of all those redundant bang buttons, pack objects and debugging number objects has made a big difference. I have to say everything is running much faster and smoother now!

for "constants" or for patch initialisation i write [list 40 17], which is only another name for [pack], but let´s you distinguish between "constants" and "variables" better when reading the patch later.

in respect of your original question the answer is that you generally want to remove all GUI objects in the final version of a sequencer patch.

otoh, often you have to find the right balance between readability, ease of patching, and CPU optimisation.

for example when you need something "bang, 40 127" regulary, maybe it is time to create an abstraction for that kind of stuff:


for "constants" or for patch initialisation i write [list 40 17], which is only another name for [pack], but let´s you distinguish between "constants" and "variables" better when reading the patch later.

in respect of your original question the answer is that you generally want to remove all GUI objects in the final version of a sequencer patch.

otoh, often you have to find the right balance between readability, ease of patching, and CPU optimisation.
for example when you need something "bang, 40 127" regulary, maybe it is time to create an abstraction for that kind of stuff:
[t b b]
/ [list #1 #2]
/ /

"How to" with numbers?...