Pd-list January 2020

pd-list@lists.iem.at

63 participants
55 discussions

audio via HDMI output terminates Pd
by Csaba Láng 21 Jan '20

21 Jan '20

Dear list, I am trying to play video with synced audio on HDMI output, but after 10-15 seconds Pd dies with an error: pd: pcm.c:1168: snd_pcm_prepare: Assertion `pcm' failed. Pd: signal 6 Can you help me to fix this issue? Ubuntu 18.04 with ALSA Best, Popesz

8 18

sigmund~ analysis issue
by João Pais 19 Jan '20

19 Jan '20

Hello list, I'm modernizing the patch doc\4.data.structures\14.partialtracer.pd, and ran into a strange issue: when a sample is loaded and an analysis is made, everything is ok. But, when a 2nd analysis is made, the partials are much higher, and the resynthesis isn't as good. As example, here are the first 2 frames of sigmund's output, analysing the bell.aiff sound. It's also strange that since the sound is stored in a table, the results are different. The parameters haven't been changed after the first run. The only way I find to get good results is by resetting sigmund on edit mode, or restarting the patch. 1ST RUN (OK) t: 0 141.298 0.137147 1 t: 1 385.345 0.0581239 1 t: 2 707.462 0.04726 1 t: 3 269.206 0.0434673 1 t: 4 364.112 0.0225979 1 t: 5 595.773 0.025954 1 t: 6 1084.57 0.0182461 1 t: 7 63.9805 0.015155 1 t: 8 541.068 0.0129506 1 t: 9 1049.86 0.00814875 1 t: 10 832.513 0.00709686 1 t: 11 215.332 0.00335958 1 t: 12 944.526 0.00692402 1 t: 13 1310.13 0.00669407 1 t: 14 1895.28 0.00548327 1 t: 15 888.046 0.00420553 1 t: 16 456.796 0.00381943 1 t: 17 1183.88 0.0032292 1 t: 18 757.497 0.00395218 1 t: 19 1554.4 0.00269764 1 t: 20 1290.07 0.00354588 1 t: 21 1670.57 0.0023464 1 t: 22 1414.85 0.00239386 1 t: 23 2099.85 0.00248014 1 t: 24 1225.45 0.00165636 1 t: 25 2249.42 0.00192396 1 t: 26 2127.87 0.00166951 1 t: 27 2737.03 0.00157576 1 t: 28 1770.02 0.00134567 1 t: 29 2462.81 0.00138555 1 t: 30 1473.12 0.00158225 1 t: 31 1991.32 0.00150557 1 t: 32 2505.45 0.00118963 1 t: 33 3522.37 0.00128237 1 t: 34 1400.38 0.00170432 1 t: 35 2024.19 0.00113305 1 t: 36 2983.94 0.000941453 1 t: 37 3075.74 0.00101321 1 t: 38 3286.13 0.000883695 1 t: 39 2531.29 0.000845063 1 t: 0 138.628 0.135288 0 t: 1 386.632 0.0500026 0 t: 2 705.62 0.0487652 0 t: 3 258.881 0.0428605 0 t: 4 296.177 0.0105696 1 t: 5 605.138 0.0219934 0 t: 6 1082.22 0.0180366 0 t: 7 57.4144 0.00979881 0 t: 8 535.631 0.00879348 0 t: 9 952.848 0.00944249 1 t: 10 830.594 0.00784354 0 t: 11 1630.66 0.000687276 1 t: 12 955.149 0.00600927 0 t: 13 1303.32 0.00753062 0 t: 14 1893.23 0.0056183 0 t: 15 878.553 0.00487427 0 t: 16 466.142 0.00383666 0 t: 17 1186.99 0.0048419 0 t: 18 751.237 0.0064956 0 t: 19 1547.86 0.00369452 0 t: 20 2211.92 0.000763845 1 t: 21 1665.65 0.00158778 0 t: 22 1439.33 0.00140849 0 t: 23 2108.29 0.00329683 0 t: 24 1834.18 0.000674865 1 t: 25 2250.51 0.00168626 0 t: 26 2810.52 0.000731613 1 t: 27 2738.07 0.0014678 0 t: 28 1765.87 0.00197579 0 t: 29 2459.03 0.00111085 0 t: 30 1490.06 0.00153197 0 t: 31 1981.18 0.00127681 0 t: 32 2496.56 0.00104289 0 t: 33 3523.31 0.000949688 0 t: 34 1399.56 0.00239812 0 t: 35 2022.71 0.00165475 0 t: 36 2983.59 0.00090797 0 t: 37 3075.81 0.00103291 0 t: 38 3284.22 0.000780804 0 t: 39 2368.94 0.000667367 1 2ND RUN (partials are higher) t: 0 456.796 0.00381943 0 t: 1 944.526 0.00692402 0 t: 2 364.112 0.0225979 0 t: 3 215.332 0.00335958 1 t: 4 385.345 0.0581239 0 t: 5 1290.07 0.00354588 0 t: 6 1991.32 0.00150557 0 t: 7 269.206 0.0434673 0 t: 8 888.046 0.00420553 1 t: 9 141.298 0.137147 0 t: 10 63.9805 0.015155 0 t: 11 757.497 0.00395218 0 t: 12 1084.57 0.0182461 0 t: 13 595.773 0.025954 0 t: 14 1895.28 0.00548327 0 t: 15 1049.86 0.00814875 0 t: 16 707.462 0.04726 0 t: 17 1225.45 0.00165636 1 t: 18 2462.81 0.00138555 0 t: 19 2737.03 0.00157576 1 t: 20 541.068 0.0129506 0 t: 21 832.513 0.00709686 0 t: 22 1473.12 0.00158225 0 t: 23 1310.13 0.00669407 0 t: 24 1770.02 0.00134567 1 t: 25 2531.29 0.000845063 0 t: 26 1414.85 0.00239386 0 t: 27 2024.19 0.00113305 0 t: 28 2505.45 0.00118963 1 t: 29 3522.37 0.00128237 1 t: 30 2099.85 0.00248014 0 t: 31 1670.57 0.0023464 0 t: 32 1400.38 0.00170432 1 t: 33 1554.4 0.00269764 0 t: 34 2127.87 0.00166951 0 t: 35 2983.94 0.000941453 1 t: 36 2249.42 0.00192396 0 t: 37 1183.88 0.0032292 0 t: 38 3075.74 0.00101321 1 t: 39 3286.13 0.000883695 1 t: 0 466.142 0.00383666 0 t: 1 955.149 0.00600927 0 t: 2 296.177 0.0105696 1 t: 3 952.848 0.00944249 1 t: 4 386.632 0.0500026 0 t: 5 1630.66 0.000687276 1 t: 6 1981.18 0.00127681 0 t: 7 258.881 0.0428605 0 t: 8 878.553 0.00487427 0 t: 9 138.628 0.135288 0 t: 10 57.4144 0.00979881 0 t: 11 751.237 0.0064956 0 t: 12 1082.22 0.0180366 0 t: 13 605.138 0.0219934 0 t: 14 1893.23 0.0056183 0 t: 15 2211.92 0.000763845 1 t: 16 705.62 0.0487652 0 t: 17 1834.18 0.000674865 1 t: 18 2459.03 0.00111085 0 t: 19 2738.07 0.0014678 0 t: 20 535.631 0.00879348 0 t: 21 830.594 0.00784354 0 t: 22 1490.06 0.00153197 0 t: 23 1303.32 0.00753062 0 t: 24 1765.87 0.00197579 0 t: 25 2810.52 0.000731613 1 t: 26 1439.33 0.00140849 0 t: 27 2022.71 0.00165475 0 t: 28 2496.56 0.00104289 0 t: 29 3523.31 0.000949688 0 t: 30 2108.29 0.00329683 0 t: 31 1665.65 0.00158778 0 t: 32 1399.56 0.00239812 0 t: 33 1547.86 0.00369452 0 t: 34 2368.94 0.000667367 1 t: 35 2983.59 0.00090797 0 t: 36 2250.51 0.00168626 0 t: 37 1186.99 0.0048419 0 t: 38 3075.81 0.00103291 0 t: 39 3284.22 0.000780804 0

1 0

clone vs. dynamic patching
by João Pais 19 Jan '20

19 Jan '20

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. (in case relevant - on windows) Best, jmmmp

5 6

Re: [PD] [PD-announce] vstplugin~ v0.3.1 - critical bug fix release
by Christof Ressi 19 Jan '20

19 Jan '20

> 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" <christof.ressi(a)gmx.at> > An: "pd announce" <pd-announce(a)lists.iem.at> > 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-announce(a)lists.iem.at > https://lists.puredata.info/listinfo/pd-announce > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

[PD-announce] vstplugin~ v0.3.1 - critical bug fix release
by Christof Ressi 18 Jan '20

18 Jan '20

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-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

1 0

Re: [PD] clone vs. dynamic patching
by Christof Ressi 18 Jan '20

18 Jan '20

> 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" <timvets(a)gmail.com> An: "Christof Ressi" <christof.ressi(a)gmx.at> Betreff: Re: Re: [PD] clone vs. dynamic patching Op za 18 jan. 2020 om 19:23 schreef Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@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" <timvets@gmail.com[mailto:timvets@gmail.com]> An: Pd-List <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> Betreff: Re: [PD] clone vs. dynamic patching Op za 18 jan. 2020 om 18:03 schreef Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at][mailto:christof.ressi@gmx.at[mailto:christof.ressi@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" <oliver@klingt.org[mailto:oliver@klingt.org][mailto:oliver@klingt.org[mailto:oliver@klingt.org]]> > An: Pd-List <pd-list@lists.iem.at[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 > > best > > oliver > > > > _______________________________________________ > Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto: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/li… > _______________________________________________ Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at][mailto: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/li… 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/li…

1 0

Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp?
by Christof Ressi 17 Jan '20

17 Jan '20

Just because it doesn't crash in your specific use case doesn't mean it isn't dangerous... > At least, for my usage case, having a subpatch fixed to overlap 2 of > the parent, I can't crash it either. I mean, I really thrashed it. > It takes a lot of time when it's allocating signals up to 2^22---but > did not crash, resumed. I put the block size on a power of 2 > quantized vertical slider and slung it around. There's not much > latency in changing them in the low blocksizes up to 131,072. Not > bad. > > > > On Fri, Jan 17, 2020 at 3:54 AM Christof Ressi <christof.ressi(a)gmx.at> wrote: > > > > > Or a *great* idea > > > > Certainly not. As I've said, it's possible to crash Pd in various ways. > > > > Christof > > > > > Gesendet: Freitag, 17. Januar 2020 um 07:36 Uhr > > > Von: "Charles Z Henry" <czhenry(a)gmail.com> > > > An: Pd-List <pd-list(a)lists.iem.at> > > > Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp? > > > > > > On Thu, Jan 16, 2020 at 1:03 PM Christof Ressi <christof.ressi(a)gmx.at> wrote: > > > > > > > > it's certainly not a good idea to (possibly) modify the DSP graph while it's being built. > > > > > > Or a *great* idea > > > > > > >As I said, the external should use a clock to schedule the message for the next tick. > > > > > > Here's what seems possible: > > > The canvas "dsp" method gets called on toplevel canvases. It adds all > > > the objects in the canvas with "dsp" methods to an unsorted list. > > > Then, in ugen_done_graph, the main work of setting up the dspcontext > > > struct from block~/switch~ happens. It allocates all the signals, and > > > ugen_doit puts each chain of objects in a queue to have their "dsp" > > > methods run. Then it finally reaches a sub-patch (a canvas object), > > > and its "dsp" method gets called. > > > > > > The outcome depends on which runs first--the blocksize~ "dsp" method > > > or the sub-patch canvas "dsp" method. Sub-patch blocksizes could > > > still be set, during graph generation, because the block~ parameters > > > aren't even relevant until the sub-patch "dsp" method. > > > > > > With no signal inlets and no outlets, there's nothing there to force > > > it to come before/after the sub-patch "dsp" method. > > > > > > If blocksize~ had a signal inlet, you could connect it to a subpatch > > > output and be guaranteed that the sub-patch "dsp" method will be > > > called before the blocksize~ "dsp" > > > > > > And vice versa (the interesting case): if blocksize~ has a signal > > > outlet connected to some sub-patch inlet, then it's possible to set > > > the sub-patch block~/switch~ parameters during the graph generation, > > > right before they are to be used. > > > But.... I still have questions. Will the block~ "set" method trigger > > > the dsp graph to be rebuilt, at some point when it's already trying to > > > build the graph? What would happen if it did? > > > > > > > > Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr > > > > > Von: "Charles Z Henry" <czhenry(a)gmail.com> > > > > > An: Pd-List <pd-list(a)lists.iem.at> > > > > > Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp? > > > > > > > > > > On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi <christof.ressi(a)gmx.at> wrote: > > > > > > > > > > > > I also think that messaging an outlet in the "dsp" method is not a good idea and it's better to use a clock with delay 0. The user might take the output of [blocksize~] and accidentally do something which interferes with DSP graph generation, e.g. by resizing an array, creating/deleting objects, etc. > > > > > > > > > > > > Christof > > > > > > > > > > Yes it *could*, but I'm unclear on the timing. I've read and > > > > > consulted the d_ugen.c code recently but . The block parameters are > > > > > derived from block/switch and coded into the dspcontext struct which > > > > > gets generated for each canvas. The parameters have to be known > > > > > before "dsp" gets called in the current canvas (which would trigger > > > > > the "blocksize~" output), but is the sub-patch dspcontext already > > > > > built? I'll try to follow up later today and try to answer it > > > > > > > > > > That ambiguity could be resolved by looking at the "bang~" code. I > > > > > just think it's an interesting question what is possible to happen as > > > > > it is currently written > > > > > > > > > > bang~ sends properly timed messages by using: > > > > > t_clock *x_clock; //in the data structure > > > > > > > > > > x->x_clock = clock_new(x, (t_method)bang_tilde_tick); // in the "new" method > > > > > > > > > > static void bang_tilde_tick(t_bang *x) // added "tick" method > > > > > { outlet_bang(x->x_obj.ob_outlet); } > > > > > > > > > > and > > > > > clock_delay(x->x_clock, 0); // in the "perform" routine > > > > > > > > > > Chuck > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pd-list(a)lists.iem.at mailing list > > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pd-list(a)lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > > > >

1 0

recent Pd versions on older ubuntu studio computers
by info＠hansroels.be 17 Jan '20

17 Jan '20

Hi, Is an installation of a /recent/ version of Pd vanilla (0.49 or 0.50) possible on an older linux computer? and is this somehow related to the libc6 versions of the operating systems? I am trying to install Pd 0.50.2 on two older Ubuntu Studio laptops, one has Ubuntu 14.04, the other Ubuntu 16.04. When I try to install the deb package from https://deb.debian.org/debian/pool/main/p/puredata/ I get a dependencies error, saying that I need a higher version of libc6. Is it a solution to try compiling the Pd source code on both machines? or is the only solution to upgrade the whole Ubuntu Studio version? (...which isn't possible on one of these machines). Hans --

5 9

Any problems else/blocksize changing subpatch blocking during dsp?
by Charles Z Henry 17 Jan '20

17 Jan '20

Hi list, Is there any potential problem using [else/blocksize~ ] and setting the switch~ settings of a subpatch? blocksize~.c tells me that outlet_float is called during the "dsp" method. Will "set" messages to sub-patches with [switch~] during "dsp" interfere with dsp graph generation? I have a solution (a subpatch named "switchbang") to delay the output by one dsp cycle. [inlet] // bang input | [switch~] [bang~] | [outlet] But I'm wondering if I'm being overly cautious. Chuck

4 11

Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp?
by Christof Ressi 17 Jan '20

17 Jan '20

> Or a *great* idea Certainly not. As I've said, it's possible to crash Pd in various ways. Christof > Gesendet: Freitag, 17. Januar 2020 um 07:36 Uhr > Von: "Charles Z Henry" <czhenry(a)gmail.com> > An: Pd-List <pd-list(a)lists.iem.at> > Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp? > > On Thu, Jan 16, 2020 at 1:03 PM Christof Ressi <christof.ressi(a)gmx.at> wrote: > > > > it's certainly not a good idea to (possibly) modify the DSP graph while it's being built. > > Or a *great* idea > > >As I said, the external should use a clock to schedule the message for the next tick. > > Here's what seems possible: > The canvas "dsp" method gets called on toplevel canvases. It adds all > the objects in the canvas with "dsp" methods to an unsorted list. > Then, in ugen_done_graph, the main work of setting up the dspcontext > struct from block~/switch~ happens. It allocates all the signals, and > ugen_doit puts each chain of objects in a queue to have their "dsp" > methods run. Then it finally reaches a sub-patch (a canvas object), > and its "dsp" method gets called. > > The outcome depends on which runs first--the blocksize~ "dsp" method > or the sub-patch canvas "dsp" method. Sub-patch blocksizes could > still be set, during graph generation, because the block~ parameters > aren't even relevant until the sub-patch "dsp" method. > > With no signal inlets and no outlets, there's nothing there to force > it to come before/after the sub-patch "dsp" method. > > If blocksize~ had a signal inlet, you could connect it to a subpatch > output and be guaranteed that the sub-patch "dsp" method will be > called before the blocksize~ "dsp" > > And vice versa (the interesting case): if blocksize~ has a signal > outlet connected to some sub-patch inlet, then it's possible to set > the sub-patch block~/switch~ parameters during the graph generation, > right before they are to be used. > But.... I still have questions. Will the block~ "set" method trigger > the dsp graph to be rebuilt, at some point when it's already trying to > build the graph? What would happen if it did? > > > > Gesendet: Donnerstag, 16. Januar 2020 um 19:07 Uhr > > > Von: "Charles Z Henry" <czhenry(a)gmail.com> > > > An: Pd-List <pd-list(a)lists.iem.at> > > > Betreff: Re: [PD] Any problems else/blocksize changing subpatch blocking during dsp? > > > > > > On Thu, Jan 16, 2020 at 10:03 AM Christof Ressi <christof.ressi(a)gmx.at> wrote: > > > > > > > > I also think that messaging an outlet in the "dsp" method is not a good idea and it's better to use a clock with delay 0. The user might take the output of [blocksize~] and accidentally do something which interferes with DSP graph generation, e.g. by resizing an array, creating/deleting objects, etc. > > > > > > > > Christof > > > > > > Yes it *could*, but I'm unclear on the timing. I've read and > > > consulted the d_ugen.c code recently but . The block parameters are > > > derived from block/switch and coded into the dspcontext struct which > > > gets generated for each canvas. The parameters have to be known > > > before "dsp" gets called in the current canvas (which would trigger > > > the "blocksize~" output), but is the sub-patch dspcontext already > > > built? I'll try to follow up later today and try to answer it > > > > > > That ambiguity could be resolved by looking at the "bang~" code. I > > > just think it's an interesting question what is possible to happen as > > > it is currently written > > > > > > bang~ sends properly timed messages by using: > > > t_clock *x_clock; //in the data structure > > > > > > x->x_clock = clock_new(x, (t_method)bang_tilde_tick); // in the "new" method > > > > > > static void bang_tilde_tick(t_bang *x) // added "tick" method > > > { outlet_bang(x->x_obj.ob_outlet); } > > > > > > and > > > clock_delay(x->x_clock, 0); // in the "perform" routine > > > > > > Chuck > > > > > > > > > > > > _______________________________________________ > > > Pd-list(a)lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list > > > > > > > _______________________________________________ > Pd-list(a)lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list January 2020