[PD] [coll] bug

Derek Kwan derek.x.kwan at gmail.com
Sun Jan 29 09:18:23 CET 2017

> But anyway, I also wonder if the threaded version shouldn't be the default
> behaviour of cyclone's coll, because we always have the bang output to rely
> on and tell us when it is done anyway. The whole purpose of its existence
> and design choice seems to be that anyway... it only makes sense if it is
> undetermined...
> so I'm thinking that if one wants the pd related behaviour that you should
> add it as a flag, say "threaded 0"

I don't think it should be threaded by default either. I think it came
up earlier on the list that Windows machines were having issues with
coll's threading? I remember reading somewhere that pthreads was unix
only and there's a separate Windows way of doing threading, which isn't
in coll quite yet. 

I did add back the bang out the 3rd inlet on instantiation when a file
argt is loaded. There was a clock x->x_clock that was only instantiated
in the threaded version that I needed to use because the methods that load
the file arg coll_bind -> collcommon_doread return before coll_new returns
so the object exist yet so there's no outlet to bang to (at least that's
what I think was going on...). I did this by adding a check in
coll_bind, where msg is the thing returned by collcommon_doread:

if(msg->m_line > 0) clock_delay(x->x_clock);

but that may have been the thing that screwed up the correct order of
things. In any case, I'll have to look at it more...


Derek Kwan

More information about the Pd-list mailing list