[PD] partconv~ outputs silence

[Alexandre Torres Porres]

> have the [partconv~] object be created before the [table]?

I tried and have it working actually, not sure how it wouldn't work like I
said

2015-07-19 16:55 GMT-03:00 IOhannes m zmölnig <zmoelnig at iem.at>:

> On 07/19/2015 08:46 PM, Alexandre Torres Porres wrote:
> > hi, what is so hard about initializing the object with a table? The
> > [cycle~] object does that really well, for example.
>
> it's very simple if the object can access the table-values directly when
> needed.
> e.g. [tabread] (we don't need to search for max-compat externals to have
> a use-case...) will check whether a table exists directly before it
> accesses it; [tabosc~] (that's [cycle~], ain't it?) and other
> dsp-objects will check whether the table exists when DSP is turned on
> (Pd guarantees that whenever a table appears or disappears the DSP is
> re-started).
>
> but some externals (including [partconv~]) are slightly different, as
> they don't access the table-values directly.
> rather they munge the data in the table into a local representation (in
> the case of [partconv~] the data will be fft-transformed), which is
> rather time-consuming.
>
> i *guess* that even for [partconv~] it would be enough to not access the
> table-data before the DSP is started.
> this might need major refactoring though.
>
> > And I don't see how it wouldn't work if the table had its contents saved,
> > for example...
>
> have the [partconv~] object be created before the [table]?
>
> gfmrdsa
> IOhannes
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150720/8d475706/attachment.html>