... getting no answer to previous post, i put the problem

again with a little broader idea, as I think such question

of building modular stuff is quite in the air... so maybe

it'd be good to discuss the right way to go (if any)

We are developping an application with Max/MSP/Jitter,

consisting in a main interface where one can load several

We are now in a phase where we'd like to distribute the soft,

and like to distribute compiled stuff to protect the synthesizers'

A good solution would be to have the main interface compiled,

say as a standalone that we could distribute, and being able to

add the synthesizers in a special folder, compiled separately from

Then, the interface should be able to share data (buffer & textures)

as well as communicating with the synthesizers.

I tried the following methods, but had drawbacks with both:

*1) Synthesizers as abstractions created with thispatcher scripts.*

Drawback: this solution seems to force synthesizers to be compiled

with the main patch, while we'd like it to be possible for the user to

add new synthesizers without recompiling the whole thing.

Drawback: if the synthesizer is compiled as a collective, the # arguments 

provided with the load message are not taken into account.

Thats what we used to use for passing message and identifying various

Also, the "shroud" message doesn't seem work with compiled .mxf patch

(while it works with .mxt): the loaded collective pop up on the screen,

while we's like to be able to open it with a message.

...I think using poly could be another solution, but I don't see how to use

it with this constraint of separate compilation from the synth...

- How to have a licenced program with plugin-like synthesizers?

- How to have a unique ID for the loaded plugins to enable

communication among the various module and main patch?

Can anyone advise on the best method(s) to program such architecture?

... getting no answer to previous post, i put the problem
again with a little broader idea, as I think such question
of building modular stuff is quite in the air...  so maybe
it'd be good to discuss the right way to go (if any)

We are developping an application with Max/MSP/Jitter,
consisting in a main interface where one can load several
synthesizers (audio & video).

We are now in a phase where we'd like to distribute the soft,
and like to distribute compiled stuff to protect the synthesizers'
authors' rights.

A good solution would be to have the main interface compiled,
say as a standalone that we could distribute, and being able to
add the synthesizers in a special folder, compiled separately from
the interface, say as *collectives*.

Then, the interface should be able to share data (buffer & textures)
as well as communicating with the synthesizers.

*1) Synthesizers as abstractions created with thispatcher scripts.*
Drawback: this solution seems to force synthesizers to be compiled
with the main patch, while we'd like it to be possible for the user to
add new synthesizers without recompiling the whole thing.

*2) Synthesizers loaded with pcontrol.*
Drawback:  if the synthesizer is compiled as a collective, the # arguments 
provided with the load message are not taken into account.
Thats what we used to use for passing message and identifying various
instances of synthesizers.
Also, the "shroud" message doesn't seem work with compiled .mxf patch
(while it works with .mxt): the loaded collective pop up on the screen,
while we's like to be able to open it with a message.

...I think using poly could be another solution, but I don't see how to use
it with this constraint of separate compilation from the synth...

Namely, the problem in short are:
- How to have a licenced program with plugin-like synthesizers?
- How to have a unique ID for the loaded plugins to enable
communication among the various module and main patch?

Can anyone advise on the best method(s) to program such architecture?
thanks
vg.


loading-compiled-module-within-bigger-architecture

> - How to have a licenced program with plugin-like synthesizers?

> - How to have a unique ID for the loaded plugins to enable

> communication among the various module and main patch?

One way would be to generally use vst's as modules. Any Max patch can be 

You could also script the collectives, and add the parameters with the 

Think about the necessity of parameters to loaded modules, you can 

instead have a receive object for initialisation and simply send your 

parameters there (this would also apply to vst's)...

Vincent Goudard wrote:
> Namely, the problem in short are:
> - How to have a licenced program with plugin-like synthesizers?
> - How to have a unique ID for the loaded plugins to enable
> communication among the various module and main patch?

One way would be to generally use vst's as modules. Any Max patch can be 
turned into a vst.

You could also script the collectives, and add the parameters with the 
script. I think that works...

Think about the necessity of parameters to loaded modules, you can 
instead have a receive object for initialisation and simply send your 
parameters there (this would also apply to vst's)...

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


loading compiled module within bigger architecture