[PD] partconv~ outputs silence
Alexandre Torres Porres
porres at gmail.com
Sun Jul 19 20:46:09 CEST 2015
hi, what is so hard about initializing the object with a table? The
[cycle~] object does that really well, for example.
And I don't see how it wouldn't work if the table had its contents saved,
attached there's a patch using cycle, the table is initialized in the patch
with a loadbang, and it still works - remembering that whenever changes are
made in the table, cycle needs to be reset so it loads the table back.
2015-07-19 15:40 GMT-03:00 Fred Jan Kraan <fjkraan at xs4all.nl>:
> On 2015-07-19 07:46 PM, IOhannes m zmölnig wrote:
> > On 07/19/2015 10:52 AM, Fred Jan Kraan wrote:
> >> Some time ago I ran into probably the same issue; how to load an
> >> array/table at load time, while said array/table is not guaranteed to
> >> have loaded yet. From within an object there is nothing like a loadbang
> >> AFAIK. I ended up setting a timer for one second (clock_new()) and load
> >> the array/timer when it finishes.
> > hmm, i wouldn't recommend that.
> > having an external initialize itself after some arbitrary time is prone
> > to hard-to-find errors. most likely the user doesn't know that something
> > special is happening after 1000ms.
> > they also might schedule their own initialization to happen "long enough
> > after startup" (e.g. 1000ms), which will then somehow conflict.
> I consider it a hack, not a proper solution. I mentioned it hoping to
> get some clue on how to fix it properly here ;-).
> > if you cannot use the table "as is" (and in [partconv~] you cannot), i
> > think the object should use an (internal) loadbang for initialization.
> > if the table is not ready at that time, the user should do a proper
> > initialization on the patch side (after all, they are the only ones who
> > can know when all required initialisation has taken place - and they can
> > only know if the object don't break the process by doing it "somewhat
> > later".
> "internal loadbang" sounds about right. I will try to find out how
> [loadbang] does its magic.
> If it cannot be made to work, the table name probably shouldn't be an
> argument to partconv~.
> >> But the good news is that just preventing partconv~ to crash shouldn't
> >> be too difficult.
> > cool, and should be fixed.
> There is already a patch ready for this that seems to work and doesn't
> look too ugly.
> > gfmdsar
> > IOhannes
> Fred Jan
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list