[PD] [coll] bug

[Derek Kwan]

> 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

-- 
Derek Kwan
www.derekxkwan.com