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

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 

https://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 

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.

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:
https://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?

passing-argument-to-compiled-mxf

> 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 

> can anyone help? or any advise? is it really unavoidable?

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 

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


> 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

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...

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 

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...

> 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 

> I don't know if my explanations make it clear... but yes... this seems 

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...

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...

passing # argument to compiled mxf