Foreach Loop
Hi, I'm new to max programming and working on some stuff for max for live. I find myself in need of a foreach loop to allow me to cycle through an enumerated type of variable size, is there a mechanism to do something like that in max?
perhaps [uzi], [zl iter] or [coll] dump?
From what you're describing I'd say you should look into [zl iter]. Variable size doesn't really matter here since zl will simply iterate through the list; no matter what size the individual objects are.
Thanks, I'll mess with that today and see if it works for me.
As someone who actually came to "traditional"/OO programming by way of max, I would strongly caution you against trying to import traditional coding paradigms directly - this could lead to a lot of pain and suffering for you. For example, local variables are available but IMO deprecated. S (send) and R (recieve) are the MAX equivalent of global vars.
I can't track it down right now, but I had a discussion on this subject awhile ago. Max is alot more like sysadmin than coding. Things may behave in unexpected ways, but they rarely crash/throw errors outright.
That said, there's always java/javascript for those who needz moar coding.
Thanks for the note jamesson, Max is definitely different to me, seems closer to designing logic circuits than writing code, but I think I can work with that, I've actually ramped up on it quicker than I expected, but I still find myself looking for things that aren't there. Not really sure how things are going to progress, I'm just doing very simple things are this point.
It looks like [zl iter] is going to work well for me, but now I find myself in need of an object like [route], but which simply outputs the first number given to its first output, second number to second output, etc, for as many outputs as it has defined. Is there a way to do that?
Also I need to know how to create a patch which has a variable number of outs, obviously this is possible since there are built ins that do it.
Yes, logic circuits are another great analogy.
re par.2, I think you need [cycle]. Re par3, I don't understand whay you need yet, please be more specific or better yet post code.
Ok thanks, I'll take a look at [cycle].
For para3 I'm thinking that I want my patcher to have either 7 outs or 5 outs (most common cases). So you can understand better I'll explain a bit of what I'm doing. I'm building a scale builder, inputs are: scale type, octave, key. Outputs are the notes of the scale, one on each output so they can be sent directly to pads, or hook directly into another patcher that I'm modifying in the current case. So for a standard scale there are 7 outputs one for each note, but I'm thinking for pentatonic scales that could drop to 5 outs. Of course I could just ignore the last 2 outputs, but I'm really asking for academic purpose as it seems to be this is possible since an object such as [route] has a number of outputs based on its parameters. Of course sometimes built in objects can do things that user created objects can't, but if this is possible I would like to know how to do it.
You can do this with javascript. If you look at the sample javascripts they start with if statements that use the arguments in the object box to set number of inputs and outputs. If you choose not to use javascripts you can probably do this with thispatcher scripting, but not worth the time IMO.
Consider what will happen when you change the number of outlets. Any connections you made will get messed up. Better to build 7 outlets and simply not use them.
What you're doing sounds a like a good fit for javascript, but that's probably because I like to do things there =P
Ok thanks, I haven't looked at using JS yet, I'm trying to learn to do everything I can with Max before starting to use JS with it. Since I already know JS I'm afraid if I start using that too soon then I won't learn what Max can do so I want to get the basics of Max down first.
IMHO a mistake. By all means use js, there is enough there that's max-specific to require plenty of learning on its own. Since you're in m4l, I would suggest avoiding the liveapi object accessible through js and sending messages to live.object, live.path, and live.observer.
Thanks for the advice, I won't wait too long before getting into JS, I've only been a Max programmer for less than a week so it's ok.
[cycle] was exactly what I was looking for, code is much prettier now, thanks ;-)
@Jamesson
Hmm, I don't quite agree with your statement that send/receive are the equivalent of global variables. The better approach to that is the 'value' object; this can contain a value (as the name indicates) which can then be used (retrieved) throughout the entire patch. By merely using the same value object and sending a bang into it.
Also much easier to use than send/receive IMO.
@Shelluser
Another great reminder that I don't know everything. Yay!
@Jamesson I'm about to venture into JS world and am curious why you recommend not using the liveapi object and instead using live.object, observer and path? I've done a lot of coding with those three, which can become pretty cluttered, some of the js coding I've seen seems a lot more elegant - I'd be happy not to venture into js though, will save me a learning curve :-)
@caris
I'm not sure what you are trying to do with multiple outputs, changing in number, but you may get benefit out of Max style routing - I use it a lot.
Use one outlet out of your patch, but prepend the output signals with a meaningful word or number.
Let me explain through something I use a lot. When you have 6 fader values coming out of one patch, send them out through the same outlet but turn them into a list, eg messages will look like: 1 0.345 or 3 5.432 which are the levels of faders 1 and 3.
if they are different types of messages eg a clock signal, a fader value and a parameter name, you can use prepending as well
Messages then look like this: fader1 0.2341 or parametername "delay volume" or clock 2:45:10
each of these messages come out of the same patcher outlet. further down you use the route object to filter out what you need where.
What is wonderful about this method is that it scales very well: if you now need to add something in your abstraction, say a pushbutton signal, you just add messages pushbutton 1/0 it will not disturb your downstream patchers because they, through [route] only listen to specific messages, the first word (parametername, fader1, clock) being the key.
As long as you are careful with spaces in your keys you should be fine. Is that useful?
forward is your friend.
M
not to forget listfunnel, and the message box capability to send things to receives.