> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
