bill spinhoven

I made an application and i would like to run multiple copy's of it.

It would be very helpful if i could give it different parameters at startup from the windows command line.

I made an application and i would like to run multiple copy's of it.
It would be very helpful if i could give it different parameters at startup from the windows command line.
Like Myapp.mxf 1 7000
is this possible?
and if so how can i implement this?

can-i-give-parameters-at-startup-to-a-mxf

Hi Bill, good to see you here (I'm on of those who did the media-art minor)

I don't have a clear answer to your question, but I would try out some objects made by francois-eudes chanfrault: 

http://francois.eudes.free.fr/software.htm

Maybe it's possible to retreive the commandline history with fe.shel, DOSHack or EnVar

I don't have a clear answer to your question, but I would try out some objects made by francois-eudes chanfrault: http://francois.eudes.free.fr/software.htm

Thanks for your reply and suggestions nice to meet a brother in arms here hope you are doing fine.

Unfortenedly the patches did not work for me.

Aldo they might come in handy at some later stage!! thanks for the link!!

I am afraid Max/Msp is missing this option shame.

Still hoping someone knows the answer for sure.

Thanks for your reply and suggestions nice to meet a brother in arms here  hope you are doing fine.
Unfortenedly the patches did not work for me.
Aldo they might come in handy at some later stage!! thanks for the link!!
I am afraid Max/Msp is missing this option  shame.
Still hoping someone knows the answer for sure.

Max is not a command line tool that you can pass argument to it at launch time. You might want to store the arguments somewhere in a text file that you will read at loadbang in your collective for instance.

You could just store them in number boxes with a preset attached, then use a [loadmess 1] to retrieve the first set, etc. Though it sounds like you want different application copies to load automatically with different numbers, which I don't think is possible, unless you run them as one big app with abstractions for each instance. Then you can use the #1 #2 etc. argument method.

Tell us what you are after, why would you want to launch several applications, instead of several patches in the same application (a standalone is simply a runtime with a collective wrapped in). You could load the same collective several times, you could have a master control patch which distributes parameters, you could create an "already opened patch" aware patch, that would load different parameters dependent what is opened already etc...

In general I have the impression, that command line interfaces are a pain in the ass anyway, why not just have a GUI where you change/set your parameters, your users will appreciate it...

And better than any command line script is a Max patch btw...

Let me please explain why i would love to use commandline arguments at startup

I am looking at rebuilding a tool i have made.

It is part of an art installation using 32 webcams

The concept was to build a modular tool that could vasilitate installations with multiple, in my case 32, webcams it can be any number of cams only the hardware you use set the limitation. I use 4 computers which each capture 8 cams an 5th computer is used to create the output and sends requests for images to the 32 programs. All communication is done in OSC. 

Basicly the tool has several algoritms for image manipulation and grabber functions. nothing to fancy yet.

As you can imagine while programming and debugging etc it is not really desireble to have to copy the new programm 32 times each time. 

So I set it up in such a way that I only work on 1 machine

and than run a batch file with something like

It starts program MyCam tells it to open the first webcam it finds lissen and output to port 7000 send data to host 192.168.100 and tell the host camera 24 is up and running.

This setup is extreemly flexable for the hardware

you can realy add as much cameras as the computer can handle it devides processor load nicely (if you are using multy core) etc etc.

extra bonus when you discover one piece of hardware is broken you can easely work around that without the whole system failing

For me making small progams that work in this way is realy the road to go. it gives an external UI and can scale (using multiple cams, mics, screens, etc etc)very easy on demand.

My windows ab works fine for me ...But i cant realy distribute it

because i have been using a 3th party DirectShow wrapper all good for me buit in the long run i want to move to something i can distribute easely to an beond windows community.

So i was thinking about max/msp hoping i can maybe get the same performance as my current program.

also I am very tempted to use OSC with parameter standarisation as proposed by jamoma. So max/msp comes to mind again.

Hope you got an bether understanding why i was hoping i could tell the program from a batch file by which name(camera number) its host will call it etc. etc. All my installations start by plugin in the mains / and pulling it out in order to stop.

In case some piece of harware din't survive the trip i just have to change 1 line of code in the batch file. and the batch has to be there any way to start the program.

Thanks for your post.
And thanks for your suggestions.
Let me please explain why i would love to use commandline arguments at startup
I am looking at rebuilding a tool i have made.
It is part of an art installation using 32 webcams
The concept was to build a modular tool that could vasilitate installations with multiple, in my case 32, webcams it can be any number of cams only the hardware you use set the limitation. I use 4 computers which each capture 8 cams an 5th computer is used to create the output and sends requests for images to the 32 programs. All communication is done in OSC. 
Basicly the tool has several algoritms for image manipulation and grabber functions. nothing to fancy yet.
As you can imagine while programming and debugging etc it is not really desireble to have to copy the new programm 32 times each time. 
So I set it up in such a way that I only work on 1 machine
and than run a batch file with something like
MyCam 1 7000 192.168.1.100 24
MyCam 2 7000 192.168.1.100 21
etc etc

It starts program MyCam tells it to open the first webcam it finds lissen and output to port 7000 send data to host 192.168.100 and tell the host camera 24 is up and running. 

This setup is extreemly flexable for the hardware
you can realy add as much cameras as the computer can handle it devides processor load nicely (if you are using multy core) etc etc.
extra bonus when you discover one piece of hardware is broken you can easely work around that without the whole system failing
For me making small progams that work in this way is realy the road to go. it gives an external UI and can scale (using multiple cams, mics, screens, etc etc)very easy on demand.  

My windows ab works fine for me ...But i cant realy distribute it
 because i have been using a 3th party DirectShow wrapper all good for me buit in the long run i want to move to something i can distribute easely to an beond windows community.
So i was thinking about max/msp hoping i can maybe get the same performance as my current program.

also I am very tempted to use OSC with parameter standarisation  as proposed by jamoma. So max/msp comes to mind again.

Hope you got an bether understanding why i was hoping i could tell the program from a batch file by which name(camera number) its host will call it etc. etc. All my installations start by plugin in the mains / and pulling it out in order to stop.
In case some piece of harware din't survive the trip i just have to change 1 line of code in the batch file. and the batch has to be there any way to start the program.


My idea would be to first start a max application on every computer and then send osc commands to these applications as soon as they have started which will connect and route the webcams as desired.

This second step can be done via scripting patchers, or loading patches into poly's or its also possible to have the max code there for a maximum nr of webcams, but only using the parts that are set with osc.

I am not sure how the performance will be compared to the dx pc method. Some parts of jitter are already multicore, but its unclear for me how this will apply to your case (the multithreaded poly option is no use for you since this only counts for audio processing). Or maybe its best to start a max application for every webcam which will enable you to do the monitoring like you used to do.

another idea: do all the image processing on the gpu with shaders in max

My idea would be to first start  a max application on every computer and then send osc commands to these applications as soon as they have started which will connect and route the webcams as desired. 

I am not sure how the performance will be compared to the dx pc method. Some parts of jitter are already multicore, but its unclear for me how this will apply to your case (the multithreaded poly option is no use for you since this only counts for audio processing). Or maybe its best to start  a max application for every webcam which will enable you to do the monitoring like you used to do.

another idea: do all the image processing on the gpu with shaders in max


Thanks again for your suggestions and ideas

It looks like I have to take the route of using OSC indeed to set ports etc.

Thanks you and all other posters for the suggestions on the forum Im now understant using the command line is not an option with max/msp.

Thanks again for your suggestions and ideas
It looks like I have to take the route of using OSC indeed to set ports etc.
Thanks you and all other posters for the suggestions on the forum Im now understant using the command line is not an option with max/msp.
So I go the extra mile.

don't forget about Emmanuel's suggestion.

unless i misunderstand, a simple text file with arguments for each app instance will basically be the same as command line arguments.

don't forget about Emmanuel's suggestion.
unless i misunderstand, a simple text file with arguments for each app instance will basically be the same as command line arguments.


bill spinhoven wrote on Mon, 07 September 2009 12:16

You don't need to run a batch file, if you simply start a single Max runtime for each computer, and communicate from your single controller machine with a Max patch some OSC messages which contain these informations. Each patch will activate a camera. You could even put all into a poly~ object and switch them on/off to your liking, which also allows to get all existing cores and processors being used. No need to change code on the remote machines for just activating cameras... 

And if you change the code, you need to restart only one copy and send a batch of OSC commands over the net to initiate all the remotes...

In the end its all about information flow. How this information is passed on doesn't matter. Command line commands would be the least interesting choice for me...

bill spinhoven wrote on Mon, 07 September 2009 12:16So I set it up in such a way that I only work on 1 machine
and than run a batch file with something like
MyCam 1 7000 192.168.1.100 24
MyCam 2 7000 192.168.1.100 21

You don't need to run a batch file, if you simply start a single Max runtime for each computer, and communicate from your single controller machine with a Max patch some OSC messages which contain these informations. Each patch will activate a camera. You could even put all into a poly~ object and switch them on/off to your liking, which also allows to get all existing cores and processors being used. No need to change code on the remote machines for just activating cameras... 
And if you change the code, you need to restart only one copy and send a batch of OSC commands over the net to initiate all the remotes...
In the end its all about information flow. How this information is passed on doesn't matter. Command line commands would be the least interesting choice for me...

"You could even put all into a poly~ object and switch them on/off to your liking, which also allows to get all existing cores and processors being used."

I don't think jitter objects benefit from the multithread option for poly's, My understanding is that this only applies to the msp objects (in the same was as muting also only applies to the msp objects)

stefan said:"You could even put all into a poly~ object and switch them on/off to your liking, which also allows to get all existing cores and processors being used."

I don't think jitter objects benefit from the multithread option for poly's, My understanding is that this only applies to the msp objects (in the same was as muting also only applies to the msp objects)


any updates on this? I'm interested in doing the same thing with a max standalone using jitter on osx.

can i give parameters at startup to a mxf ?