Thank you!
@Alexandre
I'm trying to think about what's the advantage of using something like Camomile-ELSE now, and what comes to mind is that you can compile the vst/.au/whatever with it and release/distribute as a plug in, right?
I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin.
@Alfonso
As far as i understand all the Audio/MIDI i/o, VST parameters, preset handling etc. has to be made in the main Camomile patch an the actual processing in the [pd~] subpatch.
Yes, indeed. You have to route the message from the main patch to the [pd~] object.
And as far as i understand multiple
instances of Camomile VST can exists in the same DAW project. Am i right?
Yes.
Date: Tue, 12 Jan 2021 21:49:55 +0100
From: alfonso santimone alfonso.santimone@gmail.com To: pd-list@iem.at Subject: Re: [PD] [PD-announce] Camomile v1.0.8-beta Message-ID: <CAPpSNCvPpDx9S1BHsFp___AFtExXp0AQwnV= 9vyYVj2wgk-kOA@mail.gmail.com> Content-Type: text/plain; charset="utf-8"
That's super great news!! As far as i understand all the Audio/MIDI i/o, VST parameters, preset handling etc. has to be made in the main Camomile patch an the actual processing in the [pd~] subpatch. And as far as i understand multiple instances of Camomile VST can exists in the same DAW project. Am i right?
On Tue, Jan 12, 2021, 21:25 Alexandre Torres Porres porres@gmail.com wrote:
Em ter., 12 de jan. de 2021 às 15:49, Pierre Guillot < guillotpierre6@gmail.com> escreveu:
Pd has been updated, so you can use the pd~ object (I tried and it seems to work well), and as Miller suggested, this can be used to patch
directly
in your DAW and to use externals!
Mind Blowing!!! Game Changer!!!
I'm trying to think about what's the advantage of using something like Camomile-ELSE now, and what comes to mind is that you can compile the .vst/.au/whatever with it and release/distribute as a plug in, right?
On the other hand, being able to open Pd inside any daw is great and basically the equivalent of MaxForLive, but is actually PdForEVERYTHING
:)
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot < guillotpierre6@gmail.com> escreveu:
I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin.
I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE
Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;)
Hi all, i think that Alexandre's one is an interesting question. I think we have to do a bunch of test in "real life" DAW working context. Interesting points are
VST3/AU/LV2 calling multiple instances of [pd~ ]. 2. How will the whole thing work with GUI and VST3/AU/LV2 parameters and presets. 3. Given that different DAWs deals with multi-threading in different ways (being Reaper one of the smartest in this area) how the whole thing work.
I guess is all a matter of extensive testing.
The last thing in Alexandre's message is another interesting topic.
From my point of view wouldn't be a problem but probably for
Camomile's based VST to reach the non-pd community would be better to distribute just a simple plugin.
So from the point of the VST/AU/LV2 designer the [pd~ ] solution it's really promising. From the end user's point of view not so much i guess and the Camomile-ELSE and Camomile-name_the_libraries ways seem a more viable solution.
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone
On Wed, Jan 13, 2021 at 3:41 PM Alexandre Torres Porres porres@gmail.com wrote:
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot < guillotpierre6@gmail.com> escreveu:
I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin.
I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE
Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;) _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
- How will the whole thing work with multiple instances of Camomile
VST3/AU/LV2 calling multiple instances of [pd~ ].
Each Camomile instance would use a seperate Pd subprocess. Where's the problem?
- How will the whole thing work with GUI and VST3/AU/LV2 parameters
and presets.
I guess the Camomile plugin has a regular GUI and just dispatches parameter changes, etc. to the [pd~] subprocess.
- Given that different DAWs deals with multi-threading in different
ways (being Reaper one of the smartest in this area) how
Camomile is already threadsafe. Using [pd~] changes nothing in this regard.
Christof
On 13.01.2021 16:10, alfonso santimone wrote:
Hi all, i think that Alexandre's one is an interesting question. I think we have to do a bunch of test in "real life" DAW working context. Interesting points are
- How will the whole thing work with multiple instances of Camomile
VST3/AU/LV2 calling multiple instances of [pd~ ]. 2. How will the whole thing work with GUI and VST3/AU/LV2 parameters and presets. 3. Given that different DAWs deals with multi-threading in different ways (being Reaper one of the smartest in this area) how the whole thing work.
I guess is all a matter of extensive testing.
The last thing in Alexandre's message is another interesting topic. From my point of view wouldn't be a problem but probably for Camomile's based VST to reach the non-pd community would be better to distribute just a simple plugin.
So from the point of the VST/AU/LV2 designer the [pd~ ] solution it's really promising. From the end user's point of view not so much i guess and the Camomile-ELSE and Camomile-name_the_libraries ways seem a more viable solution.
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone http://soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone http://www.facebook.com/alfonsosantimone
On Wed, Jan 13, 2021 at 3:41 PM Alexandre Torres Porres <porres@gmail.com mailto:porres@gmail.com> wrote:
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot <guillotpierre6@gmail.com <mailto:guillotpierre6@gmail.com>> escreveu: I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin. I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE <https://github.com/emviveros/Camomile-ELSE> Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;) _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I'm just trying to understand what is the difference and advantage of compiling camomile with externals
IIUC, externals are only possible via [pd~] (unless you directly link the externals with Camomile, as is the case with ELSE-Camomile). [pd~] obviously has some overhead and adds additional latency.
On the other hand, I think it wouldn't be too hard for Camomile to support externals out of the box, but they need to be compiled with PDINSTANCE. Shipping them next to the actual VST plugin might confuse some DAWs, so they should be placed in a well known directory (which could be handled by an installer). This is what "Waves" does on Windows: "%PROGRAMFILES%/VSTPlugins/Waves" only contains the "WaveShell-VST.dll" shell plugins; the actual plugins, libraries and resources reside in "Program Files (x86)/Waves".
Christof
On 13.01.2021 15:31, Alexandre Torres Porres wrote:
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot <guillotpierre6@gmail.com mailto:guillotpierre6@gmail.com> escreveu:
I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin.
I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE https://github.com/emviveros/Camomile-ELSE
Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
If [pd~ ] adds additional latency i think this is potentially problematic. if it is of some known quantity its value has to be sent to the DAW for Plugin Delay Compensation. If it is unknown it can give troubles. BTW i gonna make some tests in the next days to see how the whole thing goes about [pd~ ] in Camomile.
thanks!
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone
On Wed, Jan 13, 2021 at 4:26 PM Christof Ressi info@christofressi.com wrote:
I'm just trying to understand what is the difference and advantage of compiling camomile with externals
IIUC, externals are only possible via [pd~] (unless you directly link the externals with Camomile, as is the case with ELSE-Camomile). [pd~] obviously has some overhead and adds additional latency.
On the other hand, I think it wouldn't be too hard for Camomile to support externals out of the box, but they need to be compiled with PDINSTANCE. Shipping them next to the actual VST plugin might confuse some DAWs, so they should be placed in a well known directory (which could be handled by an installer). This is what "Waves" does on Windows: "%PROGRAMFILES%/VSTPlugins/Waves" only contains the "WaveShell-VST.dll" shell plugins; the actual plugins, libraries and resources reside in "Program Files (x86)/Waves".
Christof
On 13.01.2021 15:31, Alexandre Torres Porres wrote:
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot < guillotpierre6@gmail.com> escreveu:
I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin.
I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE
Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;)
_______________________________________________Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[pd~] takes a "-fifo <numblocks>" argument, which effectively determines the latency. And yes, plugin authors should add this to the plugin latency (https://github.com/pierreguillot/Camomile/wiki/How-to-create-new-plugins#lat...)
On 13.01.2021 19:08, alfonso santimone wrote:
If [pd~ ] adds additional latency i think this is potentially problematic. if it is of some known quantity its value has to be sent to the DAW for Plugin Delay Compensation. If it is unknown it can give troubles. BTW i gonna make some tests in the next days to see how the whole thing goes about [pd~ ] in Camomile.
thanks!
www.elgallorojorecords.bandcamp.com/ https://elgallorojorecords.bandcamp.com/ soundcloud.com/alfonsosantimone http://soundcloud.com/alfonsosantimone www.facebook.com/alfonsosantimone http://www.facebook.com/alfonsosantimone
On Wed, Jan 13, 2021 at 4:26 PM Christof Ressi <info@christofressi.com mailto:info@christofressi.com> wrote:
I'm just trying to understand what is the difference and advantage of compiling camomile with externals
IIUC, externals are only possible via [pd~] (unless you directly link the externals with Camomile, as is the case with ELSE-Camomile). [pd~] obviously has some overhead and adds additional latency. On the other hand, I think it wouldn't be too hard for Camomile to support externals out of the box, but they need to be compiled with PDINSTANCE. Shipping them next to the actual VST plugin might confuse some DAWs, so they should be placed in a well known directory (which could be handled by an installer). This is what "Waves" does on Windows: "%PROGRAMFILES%/VSTPlugins/Waves" only contains the "WaveShell-VST.dll" shell plugins; the actual plugins, libraries and resources reside in "Program Files (x86)/Waves". Christof On 13.01.2021 15:31, Alexandre Torres Porres wrote:
Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot <guillotpierre6@gmail.com <mailto:guillotpierre6@gmail.com>> escreveu: I'm not sure what do you mean by "you can compile the vst/.au/whatever with it". If you want to distribute a plugin that use externals without compiling Camomile, I guess one solution would be to ship a Pd distribution with the externals in the plugin bundle and use the [pd~] object to start a process with this embedded Pd binary (that would be able to load the external). Or you can ask the user to install Pd and the required externals if you don't want to ship a complete Pd distribution with the plugin. I'm just trying to understand what is the difference and advantage of compiling camomile with externals, which is possible and we've already made that happen at least for the ELSE-Camomile => distribution https://github.com/emviveros/Camomile-ELSE <https://github.com/emviveros/Camomile-ELSE> Not that we'll stop, now that we're here, we'll stay I guess :) but I just wanna make sure what's the motivation. And I guess the only difference is that you can ship/distribute/sell/give away just a single plug-in binary without Pd and anything 'else' ;) _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
_______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>