[PD] Lockdown performances

[Ed Kelly via Pd-list]

Hey all,
Since lockdown in the UK, I have been collaborating with a longtime 
percussionist colleague of mine using various tools, but eventually with the 
great Quacktrip~ from Miller. I've collated a few of these on a website. There 
will be more, and I have applied for a grant to keep this going. In the 
meanwhile, please enjoy what we have created so far.
http://sharktracks.co.uk/html/music.html

Ed___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Christof Ressi]

[pd~] takes a "-fifo " 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#latency)


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/ 


soundcloud.com/alfonsosantimone 
www.facebook.com/alfonsosantimone 




On Wed, Jan 13, 2021 at 4:26 PM Christof Ressi > 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
mailto:guillotpier...@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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] pd~ in Camomile and pd-Vanilla (was Is it possible to specify relative path inside pd~ object for -pddir argument ?

[Jean-Yves Gratius]

Subject:
Re: [PD] Is it possible to specify relative path inside pd~ object for 
-pddir argument ?

From:
IOhannes m zmölnig 
Date:
13/01/2021 à 15:22

To:
pd-list@lists.iem.at


On 1/13/21 10:03 AM, Jean-Yves Gratius wrote:

Hi,

I'm trying to specify a relative path


use an absolute path?
[pdcontrol[ to the rescue!

fgmrda
IOhannes


Ok for using [pdcontrol] to obtain absolute paths.

So I did some investigations (Ubuntu 18.04-5, Reaper, latest pd vanilla 
and camomile v1.0.8-beta)


1)    absolute paths for pddir and scheddir work fine, both in pd 
vanilla and in camomile, when hardcoded as arguments of pd~ box.


2)

[pd~ pddir  , pd~ start subprocess.pd(
|
[pd~ -ninsig 2 -noutsig 2 -fifo 20]

works well in pd vanilla,  although you cannot send  a [pd ~scheddir 
x(  message.  (but if you put pdsched with pd binaries, it's ok)


In my tests, (2) doesn't work in camomile.

3) Now a workaround  will be to dynamically create the pd~ box with all 
hardcoded arguments cooked from [pdcontrol]


Jean-Yves Gratius



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[alfonso santimone]

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/

soundcloud.com/alfonsosantimone
www.facebook.com/alfonsosantimone


On Wed, Jan 13, 2021 at 4:26 PM Christof Ressi 
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 <
> guillotpier...@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-l...@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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Pierre Guillot]

In a patching perspective, [pd~] object works like a subpatch so there
should not be any multi-threading or multi-instance issue. If you create a
plugin, you should create the UI in the main patch and forward the relevant
messages to the [pd~] object.

If you would like to distribute the plugin, you might want to install in a
specific path the Pd binaries that will be used by the [pd~] object, this
way you simply have to hardcode the [pd~] arguments with the installation
path. But as suggested by IOhannes, you can also use the [pdcontrol] object
to get the path of the patch and then keep the plugin library and the Pd
binaries next to each other (this might require to generate dynamically the
[pd~] object by scripting) , so you'll can simply distribute a self
contained bundle.

At this time, using [pd~] to load externals seems to be the most convenient
solution because, there is no need to compile another version of Camomile
but most of all, the code of the externals doesn't require any adaptation
for multi-instance and multi-threading (as PDINSTANCE might not be the only
change to do - for instance, if a object uses a static global t_symbol that
is not defined per thread).

At last, even if an object is compiled with the multi-threading and
multi-instance support, it doesn't seem possible to simply ship the object
library next to the patch, at least I never managed to do it because of
some unresolved symbols that I think are due to way the DAWs load the
plugin and export its internal symbols.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Christof Ressi]

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 
mailto:guillotpier...@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

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Christof Ressi]

1. 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?
2. 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.
3. 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
1. 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/ 


soundcloud.com/alfonsosantimone 
www.facebook.com/alfonsosantimone 




On Wed, Jan 13, 2021 at 3:41 PM Alexandre Torres Porres 
mailto:por...@gmail.com>> wrote:


Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot
mailto:guillotpier...@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-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[alfonso santimone]

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

soundcloud.com/alfonsosantimone
www.facebook.com/alfonsosantimone


On Wed, Jan 13, 2021 at 3:41 PM Alexandre Torres Porres 
wrote:

> Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot <
> guillotpier...@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

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Alexandre Torres Porres]

Em qua., 13 de jan. de 2021 às 05:58, Pierre Guillot <
guillotpier...@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

Re: [PD] Is it possible to specify relative path inside pd~ object for -pddir argument ?

[IOhannes m zmölnig]

On 1/13/21 10:03 AM, Jean-Yves Gratius wrote:

Hi,

I'm trying to specify a relative path


use an absolute path?
[pdcontrol[ to the rescue!

fgmrda
IOhannes



OpenPGP_signature
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Is it possible to specify relative path inside pd~ object for -pddir argument ?

[Jean-Yves Gratius]

Hi,

I'm trying to specify a relative path as argument in the pd~ object 
(using -pddir flag), in order to start a specific copy of pd 
application, located in a relative path, but without success.


Did I miss any particular syntax ?

PS : I want to write a camomile VST3 plugin that launches a pd 
subprocess via pd~, and I would like to include the pure data 
distribution inside my plugin folder structure.



Thanks




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Camomile v1.0.8-beta

[Pierre Guillot]

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 
> To: pd-l...@iem.at
> Subject: Re: [PD] [PD-announce] Camomile v1.0.8-beta
> Message-ID:
>  9vyyvj2wgk-...@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 
> wrote:
>
> > Em ter., 12 de jan. de 2021 às 15:49, Pierre Guillot <
> > guillotpier...@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
> :)
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list