start standalone with arguments

Nov 13, 2006 at 2:29pm

start standalone with arguments

hello list.

i made a quick search about this, but couldn’t find something.

is it possible to pass argmuents to a standalone-application when starting them in terminal?
like this:

blabla/theapp.app/Contents/MacOS/theapp arg1 arg2 arg3

i want to catch the arguments in the patch then…

thx
ingo

#28676
Nov 18, 2006 at 6:34am

ingo randolf wrote:
> is it possible to pass argmuents to a standalone-application when
> starting them in terminal? like this:
>
> blabla/theapp.app/Contents/MacOS/theapp arg1 arg2 arg3

I’d really like to know what the use of this akward way of calling a
program would be. I guess its possible in Pd as there are much more
geeks who think the commandline is the best interface for computers. I
am sure there are more convenient ways to do what you want to do, but
who knows, I’d like to be enlightened…

If you need to pass arguments from the user, its better to put it into
the user interface of your standalone (and save preferences), if you
want to do some automation process, you can pass information from other
programms to Max via OSC or alike. If you want to call some unix tools,
you can call them from Max and get their output into Max with shell…
(I tend to use Max instead of the terminal…)

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#88333
Nov 24, 2006 at 1:09pm

well, i think the commandline is in fact a good and fast tool, not only for accessing data on a computer, but to do various jobs for you, its a sctipting-language itself.
think that a lot of command you do in a UI are in fact such calls.

anyway. i dont want to call an application that way because of the pure pleasure of using the commandline… in fact i have two programms (but could be any number) that are the same, only differing in a couple of parameters. i can not do this as patchers inside another patch.
for stability and performance reasons every program needs to have its own system-time and should run in an own thread scheduled by the system and not by max.

to get more specific, one of the parameters i want to pass is an identifier to which the program should react to. an ID if you want, or a port on which the program should listen to.

so, if you know a way to do that, without producing copies of the one programm (where to change the portnumber per hand) please enlighten me…

well… a way i could think doing this is to get the port automatically and choose another one if the one trying to bind is already in use. after succesfull binding every program could tell another patch (working like a hub) the ports. which works fine if you use it on a single machine. using this method in a network situation, where every computer runs those programs, using totally different ports, is getting a big mess…

i think it would be an elegant way to use parameter-passing on startup of applications to deal with this kind of problem.
well using an object inside max passing the some parameters is in fact the same…

maybe i think just the wrong direction, and this problem is not hard to solve…

io

#88334
Nov 24, 2006 at 1:10pm

.

#88335
Nov 24, 2006 at 1:50pm

Am 24.11.2006 um 14:09 schrieb ingo randolf:
> to get more specific, one of the parameters i want to pass is an
> identifier to which the program should react to. an ID if you want, or
> a port on which the program should listen to.

I didn’t get from where you want to call your standalone (another Max
standalone?), but couldn’t you try writing to a small config.txt file
inside the app bundle you want to call (or elsewhere in its searchpath)
prior to launching and parse that with the text object on startup?

cheers, g.

#88336
Nov 24, 2006 at 6:42pm

> I didn’t get from where you want to call your standalone (another Max
> standalone?), but couldn’t you try writing to a small config.txt file
> inside the app bundle you want to call (or elsewhere in its searchpath)
> prior to launching and parse that with the text object on startup?

this is not a bad workaround.
thanks!! should work for this purpose.

ingo

#88337

You must be logged in to reply to this topic.