Re: [PD] [PD-announce] vstplugin~ v0.3.1 - critical bug fix release
> But first you need to clear the plugin cache (VSTPlugin.clear) Sorry, this should read: But first you need to clear the plugin cache with [search_clear 1(. Christof > Gesendet: Samstag, 18. Januar 2020 um 23:42 Uhr > Von: "Christof Ressi" > An: "pd announce" > Betreff: [PD] [PD-announce] vstplugin~ v0.3.1 - critical bug fix release > > Dear list, > > I've just released vstplugin~ v0.3.1 which contains critical bug fixes. > > NOTE: If you’ve already been using vstplugin~, please upgrade and read the > changelog below! > > Binaries are available on Deken or here: > https://git.iem.at/pd/vstplugin/releases > > Please report any bugs at https://git.iem.at/pd/vstplugin/issues. > > Cheers, > > Christof > > --- > > Changelog > > > ### bug fixes > > * fixed wrong VST3 plugin ID. The main issue was that VST3 preset files > couldn’t be opened in other VST hosts and vice versa. > > NOTE: You can still open old “wrong” preset files, but this might go away in > future versions, so you’re advised to open and save your old VST3 presets to > “convert” them to the new correct format. > But first you need to clear the plugin cache (VSTPlugin.clear) and do a new > search to update the plugin IDs. Sorry for the inconvenience! > > * fixed possible crash when opening plugins asynchronously (because of a race > condition) > > * fixed possible crash when quitting the Server (especially on macOS) > > * fixed crash with certain VST3 plugins when saving presets > > * disable window resizing if the GUI editor has a fixed size > > > ### features > > resizable VST3 GUI editors are now supported > > > > > ___ > Pd-announce mailing list > pd-annou...@lists.iem.at > https://lists.puredata.info/listinfo/pd-announce > ___ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] vstplugin~ v0.3.1 - critical bug fix release
Dear list, I've just released vstplugin~ v0.3.1 which contains critical bug fixes. NOTE: If you’ve already been using vstplugin~, please upgrade and read the changelog below! Binaries are available on Deken or here: https://git.iem.at/pd/vstplugin/releases Please report any bugs at https://git.iem.at/pd/vstplugin/issues. Cheers, Christof --- Changelog ### bug fixes * fixed wrong VST3 plugin ID. The main issue was that VST3 preset files couldn’t be opened in other VST hosts and vice versa. NOTE: You can still open old “wrong” preset files, but this might go away in future versions, so you’re advised to open and save your old VST3 presets to “convert” them to the new correct format. But first you need to clear the plugin cache (VSTPlugin.clear) and do a new search to update the plugin IDs. Sorry for the inconvenience! * fixed possible crash when opening plugins asynchronously (because of a race condition) * fixed possible crash when quitting the Server (especially on macOS) * fixed crash with certain VST3 plugins when saving presets * disable window resizing if the GUI editor has a fixed size ### features resizable VST3 GUI editors are now supported ___ Pd-announce mailing list pd-annou...@lists.iem.at https://lists.puredata.info/listinfo/pd-announce ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] clone vs. dynamic patching
> Am I right in thinking that this is however only copies of one and the same > abstraction? Yes, that's correct. So in your case dynamic patching might be still the easier solution. Actually, it would be nice to have some kind of object which can load abstractions on the fly. It doesn't have to be [clone]. Christof Gesendet: Samstag, 18. Januar 2020 um 19:50 Uhr Von: "tim vets" An: "Christof Ressi" Betreff: Re: Re: [PD] clone vs. dynamic patching Op za 18 jan. 2020 om 19:23 schreef Christof Ressi mailto:christof.re...@gmx.at]>:> Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet, > rather than having parallel copies of one abstraction...? You can do this with [send~]/[receive~]: each abstraction could have a [receive~] based on its instance number, e.g. [r~ /foo/$1], and also a [send~] which you can route to wherever you want, e.g. to the next instance: [loadbang] -> [f $1] -> [+ 1] -> [set /foo/$1( -> [send~] You can feed a signal into [clone] with [send~ /foo/0] and in the last instance you can send the signal to a [receive~] outside of clone. Alternatively, only the first instance could read from the [inlet~] and only the last instance could write to the [outlet~] by using [*~]. You can pass the total number of instances, so each instance knows whether it's the last one. Hi Christof, thanks for this, interesting! Am I right in thinking that this is however only copies of one and the same abstraction? What if I want to, say, load a bass-synth abstraction and route it through some sound effect, say a flanger? I'm currently working on a patch that should become dynamically reconfigurable, so that you can load up a new synth with some effects of your choosing... So far, the only way I could come up with is dynamic patching the old-fashioned way. I'm open to suggestions otherwise! Tim Christof Gesendet: Samstag, 18. Januar 2020 um 18:30 Uhr Von: "tim vets" mailto:timv...@gmail.com]> An: Pd-List mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] clone vs. dynamic patching Op za 18 jan. 2020 om 18:03 schreef Christof Ressi mailto:christof.re...@gmx.at][mailto:christof.re...@gmx.at[mailto:christof.re...@gmx.at]]>:I always use [clone] when I need several instances of an abstraction. Dynamic patching is a hack and shouldn't be used anymore for this purpose. Is there a way to make other kinds of structures inside [clone] though? Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet, rather than having parallel copies of one abstraction...? > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). That would be useful and it's actually on my to-do-list :-). But usually I just allocate the max. number of instances I need and simply "disable" instances I don't need. I think this is generally the better approach for cloned DSP objects (using [switch~], because dynamically changing the number of voices wouldn't be realtime safe anyway... Christof > Gesendet: Samstag, 18. Januar 2020 um 16:46 Uhr > Von: "oliver" > mailto:oli...@klingt.org][mailto:oli...@klingt.org[mailto:oli...@klingt.org]]> > An: Pd-List > mailto:pd-list@lists.iem.at][mailto:pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]]> > Betreff: Re: [PD] clone vs. dynamic patching > > João Pais wrote: > > Hello list, > > > > I didn't try clone yet, I always worked with dynamic patching for > > similar issues. For those who are knowledgeable, I would like to ask: is > > there any advantage of clone against dynamic patching when using the > > same circuit, or is it the same? > > This pertains to patches working on both control and signal input/output. > > > > if you are familiar with MAX: > > [clone] is nearly the same as [poly~] > > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). i hope miller has plans to implement this in the future. > > right now, all you can do is a combination of using [clone] and dynamic > patching if you want to change the number of instances on the fly > (destroy the old clone object and re-create it with new arguments with > PD messages). > > i used [clone] on several occasions and find it extremely useful, as you > can directly edit the original source and see the results (as opposed to > MAX). > > i would say the best use case is a situation, where you need let's say > 10 or more copies of a patch (i.e. for parameter organisation, > oscillator banks etc...). basically it's the same as creating multiple > abstractions where you do the message routing internally with a creation > argument > > [abs 1] > [abs 2] > [abs 3] > [abs 4] etc... > > so, no - there's no direct ADVANTAGE over dynamic patching but in > general i think it's the better and clearer concept
Re: [PD] clone vs. dynamic patching
> Two abstractions a and b for example, with the output of a connected to b and > b connected to [clone]s outlet, > rather than having parallel copies of one abstraction...? You can do this with [send~]/[receive~]: each abstraction could have a [receive~] based on its instance number, e.g. [r~ /foo/$1], and also a [send~] which you can route to wherever you want, e.g. to the next instance: [loadbang] -> [f $1] -> [+ 1] -> [set /foo/$1( -> [send~] You can feed a signal into [clone] with [send~ /foo/0] and in the last instance you can send the signal to a [receive~] outside of clone. Alternatively, only the first instance could read from the [inlet~] and only the last instance could write to the [outlet~] by using [*~]. You can pass the total number of instances, so each instance knows whether it's the last one. Christof Gesendet: Samstag, 18. Januar 2020 um 18:30 Uhr Von: "tim vets" An: Pd-List Betreff: Re: [PD] clone vs. dynamic patching Op za 18 jan. 2020 om 18:03 schreef Christof Ressi mailto:christof.re...@gmx.at]>:I always use [clone] when I need several instances of an abstraction. Dynamic patching is a hack and shouldn't be used anymore for this purpose. Is there a way to make other kinds of structures inside [clone] though? Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet, rather than having parallel copies of one abstraction...? > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). That would be useful and it's actually on my to-do-list :-). But usually I just allocate the max. number of instances I need and simply "disable" instances I don't need. I think this is generally the better approach for cloned DSP objects (using [switch~], because dynamically changing the number of voices wouldn't be realtime safe anyway... Christof > Gesendet: Samstag, 18. Januar 2020 um 16:46 Uhr > Von: "oliver" mailto:oli...@klingt.org]> > An: Pd-List mailto:pd-list@lists.iem.at]> > Betreff: Re: [PD] clone vs. dynamic patching > > João Pais wrote: > > Hello list, > > > > I didn't try clone yet, I always worked with dynamic patching for > > similar issues. For those who are knowledgeable, I would like to ask: is > > there any advantage of clone against dynamic patching when using the > > same circuit, or is it the same? > > This pertains to patches working on both control and signal input/output. > > > > if you are familiar with MAX: > > [clone] is nearly the same as [poly~] > > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). i hope miller has plans to implement this in the future. > > right now, all you can do is a combination of using [clone] and dynamic > patching if you want to change the number of instances on the fly > (destroy the old clone object and re-create it with new arguments with > PD messages). > > i used [clone] on several occasions and find it extremely useful, as you > can directly edit the original source and see the results (as opposed to > MAX). > > i would say the best use case is a situation, where you need let's say > 10 or more copies of a patch (i.e. for parameter organisation, > oscillator banks etc...). basically it's the same as creating multiple > abstractions where you do the message routing internally with a creation > argument > > [abs 1] > [abs 2] > [abs 3] > [abs 4] etc... > > so, no - there's no direct ADVANTAGE over dynamic patching but in > general i think it's the better and clearer concept > > best > > oliver > > > > ___ > 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]___ 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
Re: [PD] clone vs. dynamic patching
Op za 18 jan. 2020 om 18:03 schreef Christof Ressi : > I always use [clone] when I need several instances of an abstraction. > Dynamic patching is a hack and shouldn't be used anymore for this purpose. > > Is there a way to make other kinds of structures inside [clone] though? Two abstractions a and b for example, with the output of a connected to b and b connected to [clone]s outlet, rather than having parallel copies of one abstraction...? > one feature badly missing is the possibility ta allocate dynamic "voice" > > (or "instance") numbers (i.e. how many instances of an abstraction are > > created). > > That would be useful and it's actually on my to-do-list :-). But usually I > just allocate the max. number of instances I need and simply "disable" > instances I don't need. I think this is generally the better approach for > cloned DSP objects (using [switch~], because dynamically changing the > number of voices wouldn't be realtime safe anyway... > > Christof > > > Gesendet: Samstag, 18. Januar 2020 um 16:46 Uhr > > Von: "oliver" > > An: Pd-List > > Betreff: Re: [PD] clone vs. dynamic patching > > > > João Pais wrote: > > > Hello list, > > > > > > I didn't try clone yet, I always worked with dynamic patching for > > > similar issues. For those who are knowledgeable, I would like to ask: > is > > > there any advantage of clone against dynamic patching when using the > > > same circuit, or is it the same? > > > This pertains to patches working on both control and signal > input/output. > > > > > > > if you are familiar with MAX: > > > > [clone] is nearly the same as [poly~] > > > > one feature badly missing is the possibility ta allocate dynamic "voice" > > (or "instance") numbers (i.e. how many instances of an abstraction are > > created). i hope miller has plans to implement this in the future. > > > > right now, all you can do is a combination of using [clone] and dynamic > > patching if you want to change the number of instances on the fly > > (destroy the old clone object and re-create it with new arguments with > > PD messages). > > > > i used [clone] on several occasions and find it extremely useful, as you > > can directly edit the original source and see the results (as opposed to > > MAX). > > > > i would say the best use case is a situation, where you need let's say > > 10 or more copies of a patch (i.e. for parameter organisation, > > oscillator banks etc...). basically it's the same as creating multiple > > abstractions where you do the message routing internally with a creation > > argument > > > > [abs 1] > > [abs 2] > > [abs 3] > > [abs 4] etc... > > > > so, no - there's no direct ADVANTAGE over dynamic patching but in > > general i think it's the better and clearer concept > > > > best > > > > oliver > > > > > > > > ___ > > 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] clone vs. dynamic patching
I always use [clone] when I need several instances of an abstraction. Dynamic patching is a hack and shouldn't be used anymore for this purpose. > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). That would be useful and it's actually on my to-do-list :-). But usually I just allocate the max. number of instances I need and simply "disable" instances I don't need. I think this is generally the better approach for cloned DSP objects (using [switch~], because dynamically changing the number of voices wouldn't be realtime safe anyway... Christof > Gesendet: Samstag, 18. Januar 2020 um 16:46 Uhr > Von: "oliver" > An: Pd-List > Betreff: Re: [PD] clone vs. dynamic patching > > João Pais wrote: > > Hello list, > > > > I didn't try clone yet, I always worked with dynamic patching for > > similar issues. For those who are knowledgeable, I would like to ask: is > > there any advantage of clone against dynamic patching when using the > > same circuit, or is it the same? > > This pertains to patches working on both control and signal input/output. > > > > if you are familiar with MAX: > > [clone] is nearly the same as [poly~] > > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). i hope miller has plans to implement this in the future. > > right now, all you can do is a combination of using [clone] and dynamic > patching if you want to change the number of instances on the fly > (destroy the old clone object and re-create it with new arguments with > PD messages). > > i used [clone] on several occasions and find it extremely useful, as you > can directly edit the original source and see the results (as opposed to > MAX). > > i would say the best use case is a situation, where you need let's say > 10 or more copies of a patch (i.e. for parameter organisation, > oscillator banks etc...). basically it's the same as creating multiple > abstractions where you do the message routing internally with a creation > argument > > [abs 1] > [abs 2] > [abs 3] > [abs 4] etc... > > so, no - there's no direct ADVANTAGE over dynamic patching but in > general i think it's the better and clearer concept > > best > > oliver > > > > ___ > 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] clone vs. dynamic patching
Em sáb., 18 de jan. de 2020 às 12:49, oliver escreveu: > João Pais wrote: > > Hello list, > > > > I didn't try clone yet, I always worked with dynamic patching for > > similar issues. For those who are knowledgeable, I would like to ask: is > > there any advantage of clone against dynamic patching when using the > > same circuit, or is it the same? > > This pertains to patches working on both control and signal input/output. > > > > if you are familiar with MAX: > > [clone] is nearly the same as [poly~] > > one feature badly missing is the possibility ta allocate dynamic "voice" > (or "instance") numbers (i.e. how many instances of an abstraction are > created). i hope miller has plans to implement this in the future. right now, all you can do is a combination of using [clone] and dynamic > patching if you want to change the number of instances on the fly > (destroy the old clone object and re-create it with new arguments with > PD messages). > Yeah, that's a nice feature to have, why don't you open a request on github? https://github.com/pure-data/pure-data/issues ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] clone vs. dynamic patching
João Pais wrote: Hello list, I didn't try clone yet, I always worked with dynamic patching for similar issues. For those who are knowledgeable, I would like to ask: is there any advantage of clone against dynamic patching when using the same circuit, or is it the same? This pertains to patches working on both control and signal input/output. if you are familiar with MAX: [clone] is nearly the same as [poly~] one feature badly missing is the possibility ta allocate dynamic "voice" (or "instance") numbers (i.e. how many instances of an abstraction are created). i hope miller has plans to implement this in the future. right now, all you can do is a combination of using [clone] and dynamic patching if you want to change the number of instances on the fly (destroy the old clone object and re-create it with new arguments with PD messages). i used [clone] on several occasions and find it extremely useful, as you can directly edit the original source and see the results (as opposed to MAX). i would say the best use case is a situation, where you need let's say 10 or more copies of a patch (i.e. for parameter organisation, oscillator banks etc...). basically it's the same as creating multiple abstractions where you do the message routing internally with a creation argument [abs 1] [abs 2] [abs 3] [abs 4] etc... so, no - there's no direct ADVANTAGE over dynamic patching but in general i think it's the better and clearer concept best oliver ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
