Re: [PD] [coll] bug

> > I had some concerns with pthreads and Windows compat but it looks like > those aren't issues (? I don't have much experience with Windows dev) so > I think I would be fine either way. > it's working in windows! > > > And is this threaded stuff only for multi threaded processors? How does >

Re: [PD] [coll] bug

On 1/29/2017 10:24 PM, Alexandre Torres Porres wrote: So, basically, the way [coll] was designed in cyclone caused signal drop outs when reading large files, while in max that never happens. I don't see the advantage or why you'd want [coll] to behave like that in Pd... and it seems to go again

Re: [PD] [coll] bug

On Jan 29, Alexandre Torres Porres wrote: > yeah, derek was talking about our current development, where we screwed up > with the order of bangs in the unthreaded - but fixed now. > > Derek, would you care to elaborate why you think unthreaded should be the > default? > I had some concerns with

Re: [PD] [coll] bug

So, basically, the way [coll] was designed in cyclone caused signal drop outs when reading large files, while in max that never happens. I don't see the advantage or why you'd want [coll] to behave like that in Pd... and it seems to go against the max design, which prevents that from happening. >

Re: [PD] Purr Data rc4

1) Give an example, [canvasinfo] gives me "" , using -verbose -stderr, or "(pointer)" using the Purr Data console. FYI I never used pointers on Pd. 2) Lets skip that. 3) Lets skip, I have to do a new build to test that and it will take around 50min, I will when the new HTML stuff is ready to test

Re: [PD] Purr Data rc4

>>> “ds-slider.pd” is cool, also it can easly be shaped to a circle instead of >>> square, and so on, the new [draw] is cool, but: >>> how do you send values to [ds-slider]? >>Where are the values coming from? > Some saved presets in a list, [text], [coll] …,  eventually if not possible > i

Re: [PD] [coll] bug

On 1/29/2017 3:18 PM, Alexandre Torres Porres wrote: 2017-01-29 17:53 GMT-02:00 Ivica Ico Bukvic >: I also think unthreaded should be default to maintain determinacy in sync with Max hi, sorry, i dont think i get what you mean, can you elaborate on what "determin

Re: [PD] [coll] bug

2017-01-29 17:53 GMT-02:00 Ivica Ico Bukvic : > I also think unthreaded should be default to maintain determinacy in sync > with Max > hi, sorry, i dont think i get what you mean, can you elaborate on what "determinancy" is? I was asking about it in my earlier messages, I wasn't sure before and n

Re: [PD] [coll] bug

I also think unthreaded should be default to maintain determinacy in sync with Max, with threaded being optionally enabled. Best, Ico On 1/29/2017 9:25 AM, Alexandre Torres Porres wrote: yeah, derek was talking about our current development, where we screwed up with the order of bangs in the

Re: [PD] [coll] bug

yeah, derek was talking about our current development, where we screwed up with the order of bangs in the unthreaded - but fixed now. Derek, would you care to elaborate why you think unthreaded should be the default? And is this threaded stuff only for multi threaded processors? How does this wor

Re: [PD] [coll] bug

> > 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... (apologies in advance for polluting the list wit

Re: [PD] [coll] bug

> 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 i