[PD] partconv~ outputs silence

[Alexandre Torres Porres]

bugs can't be reported yet


SourceForge developer pages are presently offline.
See our Twitter feed for more information.

2015-07-19 15:46 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> 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,
> for example...
>
> 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.
>
> cheers
>
> 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
>>
>> Greetings,
>>
>> Fred Jan
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Pd-list at lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> >
>>
>> _______________________________________________
>> 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/20150719/0dac6bf4/attachment-0001.html>