passing # argument to compiled mxf
Hi,
Trying to load a collective file (.mxf) from a patcher with pcontrol object,
I discovered that the #arguments in my patch were not replaced by the
arguments given in the load message.
Its works when I do exactly the same with the corresponding .mxt…
Does anyone know if there is any way to pass argument with the filename
when loading a mxf ?
I found this post in the forum archive:
http://www.cycling74.com/forums/index.php?t=msg&goto=51312&rid=0&srch=collective+arguments#msg_51312
Should I understand there that it is not possible to have # arguments in
a collective?
Vincent
Vincent Goudard wrote:
> Me again… i had no answer to this previous post, and i’m really
> stuck on this, as it implies to modify the patches from far back in the
> past…
> can anyone help? or any advise? is it really unavoidable?
> thanks for helping
> ..vince
collectives are not ment to be used like that, you can instantiate them
inside a patcher with an argument, but why would you want to do that?
you don’t need it as collective, just load the patcher…
You might come from a Linux world, but Max is running on Mac OS and
Windows. Almost nobody is opening any document or application with
parameters. And nobody is complaining either…
I didn’t even know that it is possible to load a patcher that way with
arguments, which is cool, but I never needed it in more than 15 years…
If you load the patch instead of the collective you don’t need to modify
patches from far back in the past…
Stefan
–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com
Vincent Goudard wrote:
> The problem with this solution is the passing message system
> and also starting the audio in the loaded patch.
> I found out that I need to go inside the loaded patch and
> deactivate/reactivate the dac~, for the audio processing
> to start here..
This seems odd, as soon you add audio objects/connections audio will be
switched on/off always (assuming it was on). That means no matter if you
load, script or elsewise change the audio chain it needs to be
recompiled… The only way to avoid this are vst’s…
> As far as Linux vs Windows and Mac, it would be
> great that Max runs with Linux some day…
> but ok… just a dream, hehe
If market share increases, it might happen some day, as I believe it
would be much less hassle than the port to windows. But for the moment
nothing to even think of. And as most Linuxers are hardcore open
sourcers, its more likely they prefer Pd anyway. That would not be a
good business plan to rely on, the port might just not pay off…
>> If you load the patch instead of the collective you don’t need to
>> modify patches from far back in the past…
>
> I didn’t understand your point here… what do you mean?
At the point you made that request it was not clear that you wanted to
protect a part of the stuff. Then really go vst, loading a vst is easy,
won’t interrupt the audio chain and the modules could be used in other
hosts as well, of course for that you’d need to modify your patches, but
you get more flexibility for it…
Stefan
–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com
Vincent Goudard wrote:
> Using pcontrol + load message, the audio was still ON in the rest of the
> patch, but i had to restart the DSP *in the new loaded patch* for the
> audio processing of it to work.
> I don’t know if my explanations make it clear… but yes… this seems
> odd to me too ;)
The only occasion I could imagine would lead to something like that is
audio through send/receive (without ~) I can make connections, but they
would be only activated after restarting audio. If you script
connections within or to your subpatch this might explain it, but then
you can do this within the same script as well…
Stefan
–
Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com