Re: [PD] [coll] bug

[Matt Barber]

It's not quite like [delay] in that the delay time for this is
unpredictable. It's not just that it affects depth-first processing, but
that if you patch it wrong you may get bugs you can't always replicate;
that's not the case with [delay], whose behavior is predictable in
principle.

On Thu, Feb 2, 2017 at 11:01 AM, Alexandre Torres Porres 
wrote:

>
>
> 2017-02-02 8:06 GMT-02:00 IOhannes m zmoelnig :
>
>> i don't think a threaded version of [coll] is so out-of-the ordinary
>> that it will confuse people out of their minds.
>>
>
> thanks, me too, but you've put it really well and better than I could...
>
> I've been using Pd for a while now, and don't think I'd ever be confused
> with seeing that at all
>
>
>> oh, and of course the term "deterministic" can be stretched quite far.
>>
>
> and that's also a term that confused me, I'm more used with "depth first"
>
> Anyway, I just worked on a new help file and everything. I'm keeping the
> an option for unthreaded and all, but I'm also saying one should not use it
> and just adapt to the best patching practice instead if needed.
>
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-02-02 8:06 GMT-02:00 IOhannes m zmoelnig :

> i don't think a threaded version of [coll] is so out-of-the ordinary
> that it will confuse people out of their minds.
>

thanks, me too, but you've put it really well and better than I could...

I've been using Pd for a while now, and don't think I'd ever be confused
with seeing that at all


> oh, and of course the term "deterministic" can be stretched quite far.
>

and that's also a term that confused me, I'm more used with "depth first"

Anyway, I just worked on a new help file and everything. I'm keeping the an
option for unthreaded and all, but I'm also saying one should not use it
and just adapt to the best patching practice instead if needed.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[IOhannes m zmoelnig]

On 2017-02-02 01:14, Derek Kwan wrote:
> After a few days away from it and coming back to discuss the issue, I
> think threaded as the default makes sense GRANTED that it is well
> documented and there's an included explanation of why this differs from
> normal Pd usage. I wouldn't want users new to Pd expect all of Pd to
> work the way [coll] does as a default then getting confused as to why it
> isn't (also it looks like I accidentally left a post() in there from
> debugging but that's a different matter).

i don't think a threaded version of [coll] is so out-of-the ordinary
that it will confuse people out of their minds.
there are a number of objects that do not strictly adhere to the
depth-first paradigm, and thus break [t b b b] scheduling.
the most prominent is probably [delay]¹.

even though [delay] behaves as it does, i don't think that most will
expect Pd to behave like [delay].
(actually, a lot of new users need to get onto terms with the
depth-first principle; but once they have figured it out, they can
distinguish between the ordinary behaviour and an exception).

also, most new users probably will not start with [coll], and model
their understanding of Pd on that object.

oh, and of course the term "deterministic" can be stretched quite far.
even a non-threaded [coll] is not very deterministic: it can cause
variable length audio glitches when loading files (even with the same
file)...


fgaserd
IOhannes


¹ that's just a built-in example; other objects that do not promise to
have all their work done once their left-most inlet ist "done" include
e.g. most (all?) objects from the iemtab library, which use a
"done"-bang to signal when they have finished - even though they are not
threaded.



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

Hey, guess what else may cause audio chokes in Pd?

the dump message, which also has a bang to warn you when it is done...

hence, it also needs to be done in a threaded way ;)

2017-02-02 0:30 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

>
> There's also the best-case scenario where you have already loaded multiple
> [coll]s or where you do some offset, so you don't need to access the disk
> any more.
>
> Or if part of the RAM is used as a virtual HD.
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Pd-list <pd-list-boun...@lists.iem.at> on behalf of Matt Barber <
> brbrof...@gmail.com>
> *Sent:* Thursday, February 2, 2017 1:52 AM
> *To:* Derek Kwan
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>
> There's always a worst-case scenario for a system call blocking on loading
> even a small file that would involve dropouts. Nothing is guaranteed when
> you read from disk.
>
> On Wed, Feb 1, 2017 at 7:14 PM, Derek Kwan <derek.x.k...@gmail.com> wrote:
>
>> > Lots of thoughts here, but little time. Here are the salient points to
>> me:
>> >
>> > 1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops
>> the
>> > world in order to load the file, which routinely causes dropouts. This
>> is a
>> > constant source of disappointment and frustration to students
>> especially if.
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Matt Barber]

There's always a worst-case scenario for a system call blocking on loading
even a small file that would involve dropouts. Nothing is guaranteed when
you read from disk.

On Wed, Feb 1, 2017 at 7:14 PM, Derek Kwan  wrote:

> > Lots of thoughts here, but little time. Here are the salient points to
> me:
> >
> > 1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the
> > world in order to load the file, which routinely causes dropouts. This
> is a
> > constant source of disappointment and frustration to students especially
> if
> > they're coming from Max. But the point here is that [soundfiler] is a
> > control object, and Pd guarantees deterministic behavior for control
> > objects.
>
> Hello,
>
> After a few days away from it and coming back to discuss the issue, I
> think threaded as the default makes sense GRANTED that it is well
> documented and there's an included explanation of why this differs from
> normal Pd usage. I wouldn't want users new to Pd expect all of Pd to
> work the way [coll] does as a default then getting confused as to why it
> isn't (also it looks like I accidentally left a post() in there from
> debugging but that's a different matter).
>
> I would even post something to the Pd window if the object is threaded
> or not. I could seriously imagine if I had more patches depending on
> [coll] and determinism and if I were in a crunch, going absolutely crazy
> and frustrated as to why my patch broke. If the patch broke becaue of
> order, that can be quite subtle and if i'm familiar with an object, my
> instincts wouldn't say "hey let's go to the help file", esp if it's a
> wall of text. I know Max doesn't tell you in the Max window if it's
> threaded but this is Pd land here. So I would strongly side with well,
> first getting rid of my stupid debugging post that shouldn't be there,
> and putting in a post that says we're using threaded.
>
> More on this, I think should be clear documentation outside of running
> Pd, maybe even in the main README, even if it's a short blurb expanded
> upon somewhere else, how this library in general differs from normal Pd
> land.
>
> Anyways, the decision is a bit easier with large text files that would
> cause dropouts. Unthreaded would be unlikely to be used when you have live
> audio going on because of the dropouts unless you're making the dropouts
> part of your piece which I suppose could be pretty interesting but not a
> likely use case.
>
> The issue is with the rest of the cases and I'm a little more torn
> there. The fix is pretty clear although a pain in the butt. If your read
> is in the middle of a trigger, then anything to the left of it depending
> on the read happening first would get all kablunked. Then the fix would
> be to have that read bang coming out from [coll] be in charge of
> triggering that kablunked stuff in the proper order and this could be a
> lot of rewiring... I suppose since we're going wtih a most Max-like
> experience as possible, it would be confusing if one object wasn't as
> Max-like as the others. Anyways, that's my two cents for now.
>
> Derek
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Derek Kwan]

> Lots of thoughts here, but little time. Here are the salient points to me:
> 
> 1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the
> world in order to load the file, which routinely causes dropouts. This is a
> constant source of disappointment and frustration to students especially if
> they're coming from Max. But the point here is that [soundfiler] is a
> control object, and Pd guarantees deterministic behavior for control
> objects.

Hello,

After a few days away from it and coming back to discuss the issue, I
think threaded as the default makes sense GRANTED that it is well
documented and there's an included explanation of why this differs from
normal Pd usage. I wouldn't want users new to Pd expect all of Pd to
work the way [coll] does as a default then getting confused as to why it
isn't (also it looks like I accidentally left a post() in there from
debugging but that's a different matter).

I would even post something to the Pd window if the object is threaded
or not. I could seriously imagine if I had more patches depending on
[coll] and determinism and if I were in a crunch, going absolutely crazy
and frustrated as to why my patch broke. If the patch broke becaue of
order, that can be quite subtle and if i'm familiar with an object, my
instincts wouldn't say "hey let's go to the help file", esp if it's a
wall of text. I know Max doesn't tell you in the Max window if it's
threaded but this is Pd land here. So I would strongly side with well,
first getting rid of my stupid debugging post that shouldn't be there,
and putting in a post that says we're using threaded.

More on this, I think should be clear documentation outside of running
Pd, maybe even in the main README, even if it's a short blurb expanded
upon somewhere else, how this library in general differs from normal Pd
land.

Anyways, the decision is a bit easier with large text files that would
cause dropouts. Unthreaded would be unlikely to be used when you have live
audio going on because of the dropouts unless you're making the dropouts
part of your piece which I suppose could be pretty interesting but not a
likely use case. 

The issue is with the rest of the cases and I'm a little more torn
there. The fix is pretty clear although a pain in the butt. If your read
is in the middle of a trigger, then anything to the left of it depending
on the read happening first would get all kablunked. Then the fix would
be to have that read bang coming out from [coll] be in charge of
triggering that kablunked stuff in the proper order and this could be a
lot of rewiring... I suppose since we're going wtih a most Max-like
experience as possible, it would be confusing if one object wasn't as
Max-like as the others. Anyways, that's my two cents for now.

Derek

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-02-01 16:41 GMT-02:00 Jonathan Wilkes :

> Do we know if Ivica's implementation actually matches up with what Max is
> doing?
>

yep, I've tested it and shown it with a screenshot!
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Jonathan Wilkes via Pd-list]

> 3. So the question, as with all things cyclone, is whether it should be more 
> Pd-like or more Max-like.
Do we know if Ivica's implementation actually matches up with what Max is doing?
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-02-01 15:42 GMT-02:00 Matt Barber :

> more Max-like makes plenty of sense since there is the load termination
> bang outlet
>

totally


> but I would want the deviation from Pd-like control object behavior
> prominently documented (probably with a compare/contrast with [soundfiler]).
>

sure, I'm all for making the documentation as clear and detailed as
possible - been doing that so far, no detail is being left out, not only
when it comes to backwards compatibility issues, but also with other
details regarding inconsistencies and other max vs pd issues.


> Then, for other Pd users, we need an easy way to make it run in one DSP
> tick; all things considered I'd rather have a custom attribute for that
> than a special argument.
>

+ 1


> Might be a pain for backwards compatibility, but I think less so than
> switching the inlets of [pow~] was when it became clear it was necessary.
>

Vastly less so... the case of [pow~] was much more drastic as it really
needed changing every patch, as its structure was completely swapped. Let
me stress how nothing like that would happen to [coll], any change is only
to how it relates another possible element in the patch (trigger) in one
possible case, and only when it comes to one of its methods (out of 40).

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Matt Barber]

Lots of thoughts here, but little time. Here are the salient points to me:

1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the
world in order to load the file, which routinely causes dropouts. This is a
constant source of disappointment and frustration to students especially if
they're coming from Max. But the point here is that [soundfiler] is a
control object, and Pd guarantees deterministic behavior for control
objects.

2. Max users are used to there being no dropouts with [coll], which tells
me that it must not be deterministic in the fanout kind of way Ico
mentioned (unless Max has a very different message passing structure that
can process a message cascade over several dsp ticks in a deterministic
way).

3. So the question, as with all things cyclone, is whether it should be
more Pd-like or more Max-like. So far we've defaulted to more Max-like with
documentation, in order to support Max users who come over to Pd. In this
case I think more Max-like makes plenty of sense since there is the load
termination bang outlet, but I would want the deviation from Pd-like
control object behavior prominently documented (probably with a
compare/contrast with [soundfiler]). Then, for other Pd users, we need an
easy way to make it run in one DSP tick; all things considered I'd rather
have a custom attribute for that than a special argument. Might be a pain
for backwards compatibility, but I think less so than switching the inlets
of [pow~] was when it became clear it was necessary.

Matt


On Sun, Jan 29, 2017 at 11:43 PM, Alexandre Torres Porres 
wrote:

> 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
>> > this work on a single core rasbperry pi or something like that?
>> >
>>
>> It looks like threading works fine on single core
>
>
> cool
>
>
>> One issue that might be of concern is backwards compat with old versions
>> of Cyclone. Otherwise I'm fine with threaded as the default.
>
>
> I don't see an actual issue with that. It's more like "well, if you were
> using trigger, and then you were reading a large file (which would cause
> audio drop out anyway), you may have been using trigger instead of a bang
> from coll's 3rd outlet... and now things might change"... We can offer a
> flag for the old behaviour anyway, as it is common on Pd when such a
> revision takes place...
>
> You see, it just affects one operation: reading a file, and not all files,
> just *Large* files... and it affects it in a good way: Preventing Audio
> drop outs! As it happens in Max by the way...
>
> Nothing that a decent documentation explaining one should always rely on
> the 3rd outlet doesn't solve it.
>
> we must encourage the best practice for coll, which is relying on its 3rd
> outlet for bangs after reading a file... I don't see why offering the old
> behaviour by default is of any advantage, we'd be encouraging a bad
> practice, and sticking with a flawed design instead that causes audio drop
> outs...
>
> And let me point out that recent changes in the coll object, with the
> inclusion of the threaded version, did change the bahaviour of coll and
> compromised backwards compatibility, as the 3rd outlet bang was removed
> from the default (unthreaded) version. If backwards compatibility was such
> of a concern, that shouldn't have happened then.
>
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Dan Wilcox]

If you just need the common thread callback function and a mutex, you can do 
that with the Windows API. It’s not too difficult.

See the old thread implementation used by OpenFrameworks which uses both 
pthread & win api, depending on the platform:

ofxThread.h 
<https://github.com/openframeworks/openFrameworks/blob/6e7d325ec6f0046f281498797748da173a84aa7e/libs/openFrameworks/utils/ofThread.h>
ofxThread.cpp 
<https://github.com/openframeworks/openFrameworks/blob/6e7d325ec6f0046f281498797748da173a84aa7e/libs/openFrameworks/utils/ofThread.cpp>

Then you wouldn’t need to require win-pthreads32 or similar compatibility 
library when building.

> On Jan 29, 2017, at 9:43 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Derek Kwan <derek.x.k...@gmail.com <mailto:derek.x.k...@gmail.com>>
> Subject: Re: [PD] [coll] bug
> Date: January 29, 2017 at 8:49:56 PM MST
> To: Alexandre Torres Porres <por...@gmail.com <mailto:por...@gmail.com>>
> Cc: "pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>" 
> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
> 
> 
> 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 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.


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

>
> 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
> > this work on a single core rasbperry pi or something like that?
> >
>
> It looks like threading works fine on single core


cool


> One issue that might be of concern is backwards compat with old versions
> of Cyclone. Otherwise I'm fine with threaded as the default.


I don't see an actual issue with that. It's more like "well, if you were
using trigger, and then you were reading a large file (which would cause
audio drop out anyway), you may have been using trigger instead of a bang
from coll's 3rd outlet... and now things might change"... We can offer a
flag for the old behaviour anyway, as it is common on Pd when such a
revision takes place...

You see, it just affects one operation: reading a file, and not all files,
just *Large* files... and it affects it in a good way: Preventing Audio
drop outs! As it happens in Max by the way...

Nothing that a decent documentation explaining one should always rely on
the 3rd outlet doesn't solve it.

we must encourage the best practice for coll, which is relying on its 3rd
outlet for bangs after reading a file... I don't see why offering the old
behaviour by default is of any advantage, we'd be encouraging a bad
practice, and sticking with a flawed design instead that causes audio drop
outs...

And let me point out that recent changes in the coll object, with the
inclusion of the threaded version, did change the bahaviour of coll and
compromised backwards compatibility, as the 3rd outlet bang was removed
from the default (unthreaded) version. If backwards compatibility was such
of a concern, that shouldn't have happened then.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Ico Bukvic]

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 against the max design, which prevents 
that from happening.
In essence, yes. However, not everyone uses low power computers and it 
is possible that even on midsize machines, such dropouts will be unlikely.




So, if you issued a bang to load a coll file that fans out into a
trigger with two bangs (...) the second bang could potentially
come out before the done reading bang.


So don't use a trigger to fan it out, use the bang that comes out of 
[coll].


[coll] has a 3rd outlet that sends a bang to say when it finished 
reading a file. Its whole design purpose is just so you can do 
something after the file read is done, so one should never really use 
a [trigger] in that way because it offers another way (and a "safer" 
way) to deal with it.


Yes, but this could break traditional patches that rely on operations 
that need  to take place in a sequence within the same interrupt. I say 
this being fully aware how ironic this statement may be coming from me 
given pd-l2ork's mantra is if something is broken, we'll fix it and then 
you need to fix your patches, even though this has yet to cause any 
irreversible breakage when compared to vanilla in part because pd-l2ork 
now has the -legacy flag that enables prevalent legacy (mis)behavior 
used in historic patches. Back on topic, since you have no way of 
predicting when the bang will come back (which is the time it takes to 
load the time + clock_delay(0)), you have no way of initiating other 
operations that rely on coll's output because you don't know the file 
has loaded. This is not an issue with Max.


So, in essence, I agree with you but am also trying to make sure that 
this does not cause major backwards compatibility breakage. Hence my 
optional argument that can be named whatever you wish to name it thereby 
reserving a keyword (e.g. @threaded 1, akin to Max's Jitter attributes, 
to minimize clashes with file names and other Max idiosyncrasies).


Best,

Ico



Again, I don't see any advantage in having [coll] behaving as it was 
first designed in cyclone. If you want that just so you can ensure a 
bang from a trigger is sent out after [coll] read a file, that kind of 
assurance comes at a cost of audio drop outs, and if it doesn't really 
cause drop outs in the first place (since it is only a "potential" 
issue), it is not really doing anything... as the same would occur n 
the threaded version! the threaded version only really acts in the 
case of audio drop outs - and only when reading large files (and not 
any other kind of operation).


On the other hand, the threaded version offers the advantage of no 
audio drop outs, as it is in Max...  this happens with no compromise 
as you can (and should) rely on the 3rd outlet bang if you want to 
schedule an action for when it is done reading a file.


Looking at coll up to cyclone 0.1alpha57, it always had a 3rd outlet 
to bang when file read is done, and it would always cause drop outs 
for large files. I don't know how to consider how things are in 
cyclone 0.2, but one could consider that the threaded option is gone...


For an update of cyclone, I'm really considering the so called 
threaded version by default, as it offers a very relevant advantage of 
avoiding drop outs. This change does have a compromise, but it is not 
a big compromise and we can just document how it affects the object, 
and how one should always rely on the 3rd outlet bang instead of a 
trigger... we can also provide an option to go back to the old 
behavior, but I don't really think anyone would really opt and care 
for that as it does have a serious drop out issue.


cheers


2017-01-29 18:54 GMT-02:00 Ivica Ico Bukvic >:




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 "determinancy" is? I was asking about it in my earlier
messages, I wasn't sure before and now I really don't I get what
it's supposed to mean.

cheers




which breaks the order of execution but also ensures there are no
dropped samples.


HTH

Best,

Ico




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Derek Kwan]

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

> And is this threaded stuff only for multi threaded processors? How does
> this work on a single core rasbperry pi or something like that?
> 

It looks like threading works fine on single core, at least according to
my perusing Stack Overflow, it's just that running threads will be
paused for other threads.
(source: 
http://stackoverflow.com/questions/12997628/creating-threads-on-a-single-core-processor
 ).  So maybe something similar to unthreaded? And even then, only the Model 
As, first model Bs, 1st compute, and zero are single-core, all the rest are 
quad core. 

One issue that might be of concern is backwards compat with old versions
of Cyclone. Otherwise I'm fine with threaded as the default.

Derek




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Ico Bukvic]

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 
"determinancy" is? I was asking about it in my earlier messages, I 
wasn't sure before and now I really don't I get what it's supposed to 
mean.


cheers


It means that threaded version will report a bang when done loading in 
clock_delay(0) way. In other words as soon as possible but not 
necessarily in the same cycle of handling non-audio messages. So, if you 
issued a bang to load a coll file that fans out into a trigger with two 
bangs, in a determinant (non-threaded) way one bang hitting the coll 
would be followed by coll pushing out a done reading bang, and then the 
second bang from the trigger would come out. In a threaded way, the 
second bang could potentially come out before the done reading bang 
which breaks the order of execution but also ensures there are no 
dropped samples.


HTH

Best,

Ico
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

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 now I really don't I get what it's supposed to mean.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Ico Bukvic]

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 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 work on a single core rasbperry pi or something like that?


cheers

2017-01-29 6:32 GMT-02:00 Derek Kwan >:


>
> 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 with cyclone-dev stuff
but for those following along)

Oh, nm, it was something collcommon_doread and I fixed the unthreaded
order =)




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

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 work on a single core rasbperry pi or something like that?

cheers

2017-01-29 6:32 GMT-02:00 Derek Kwan :

> >
> > 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 with cyclone-dev stuff
> but for those following along)
>
> Oh, nm, it was something collcommon_doread and I fixed the unthreaded
> order =)
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Derek Kwan]

> 
> 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 with cyclone-dev stuff
but for those following along)

Oh, nm, it was something collcommon_doread and I fixed the unthreaded
order =) 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

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"

2017-01-28 16:16 GMT-02:00 Alexandre Torres Porres :

> 3k.txt should be 300k.txt, I increased the entries but didn't change the
> name :)
>
> 2017-01-28 16:15 GMT-02:00 Alexandre Torres Porres :
>
>> Tests in Max that stand out:
>>>
>>> Reading and writing coll files while sound is running does not cause
>>> xruns in Max, whereas in Pd it can depending on the size of the coll file
>>> and CPU utilization.
>>>
>>
>> yes, I've checked that too... Max never chokes on the audio processing.
>>
>>
>>> You are right in that determinacy is preserved in Max no matter what
>>> (e.g. read outlet bang outputs immediately after issuing the read message
>>> in logical time).
>>>
>> I'm not sure if I get what you mean by determinacy, but I have the test
>> patch attached, which I used in Purr Data.
>>
>> in the unthreaded version, I dont get a bang, but I get a warning, so
>> things are printed in this order (1, warning, 3). Warning should be the
>> same as 2, I assume, so it's the correct order... for threaded, I get (1,
>> 3, warning, 2).
>>
>> So, the order changes... and I think that is what you mean by breaking
>> determinancy, right?
>>
>> In max, if I do something similar, I always get the order of 1, 2, 3 with
>> trigger, and the audio doesn't choke.
>>
>> If I get things correctly, this would be impossible to happen in Pd,
>> right? So if you get the right order, you can also get audio chokes.
>>
>>
>>> Doing Uzi with 100k generated entries into coll object in Max and I get
>>> guaranteed crashes from these on both 6 and 7.
>>>
>>
>> well, I tested opening a file with 400k entries in Max 7 and got no audio
>> crash/choke... it loaded the file fine, taking a bit under 500ms and the
>> audio wasn't interrupted. I also had a block size of 1 and audio I/O of 32
>> samples, highest CPU consuming setting possible, it was around 13%
>>
>> see image attachment
>>
>>
>>> Best,
>>>
>>> Ico
>>>
>>>
>> Cheers
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

3k.txt should be 300k.txt, I increased the entries but didn't change the
name :)

2017-01-28 16:15 GMT-02:00 Alexandre Torres Porres :

> Tests in Max that stand out:
>>
>> Reading and writing coll files while sound is running does not cause
>> xruns in Max, whereas in Pd it can depending on the size of the coll file
>> and CPU utilization.
>>
>
> yes, I've checked that too... Max never chokes on the audio processing.
>
>
>> You are right in that determinacy is preserved in Max no matter what
>> (e.g. read outlet bang outputs immediately after issuing the read message
>> in logical time).
>>
> I'm not sure if I get what you mean by determinacy, but I have the test
> patch attached, which I used in Purr Data.
>
> in the unthreaded version, I dont get a bang, but I get a warning, so
> things are printed in this order (1, warning, 3). Warning should be the
> same as 2, I assume, so it's the correct order... for threaded, I get (1,
> 3, warning, 2).
>
> So, the order changes... and I think that is what you mean by breaking
> determinancy, right?
>
> In max, if I do something similar, I always get the order of 1, 2, 3 with
> trigger, and the audio doesn't choke.
>
> If I get things correctly, this would be impossible to happen in Pd,
> right? So if you get the right order, you can also get audio chokes.
>
>
>> Doing Uzi with 100k generated entries into coll object in Max and I get
>> guaranteed crashes from these on both 6 and 7.
>>
>
> well, I tested opening a file with 400k entries in Max 7 and got no audio
> crash/choke... it loaded the file fine, taking a bit under 500ms and the
> audio wasn't interrupted. I also had a block size of 1 and audio I/O of 32
> samples, highest CPU consuming setting possible, it was around 13%
>
> see image attachment
>
>
>> Best,
>>
>> Ico
>>
>>
> Cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-01-26 17:30 GMT-02:00 Ivica Ico Bukvic :

> Joining late to the party...
>
> Being the culprit (I wrote the threaded addition to the coll object) I am
> curious--Alexandre, do you mind elaborating how did the threaded thing
> break max-msp compatibility? If you create a coll object without the
> optional arg, you get Max behavior. If you add the optional arg you get
> threaded which theoretically breaks determinacy in favor of avoiding
> dropping samples due to file I/O in the middle of a performance.
>

sure, here's the deal, Max already has an optional 2nd argument, which is
for telling it to not look for a file with that name. This is so because
the 1st argument can be either for naming a coll object or telling it to
look for a file to load. Moreover, if you give it a file name to look for
and read, that also works as the name of the coll object, meaning that you
can have multiple coll objects with that name. But since different coll
objects with the same name already sahre the data, you don't need all of
them to read files.

Some examples:

[coll name 1] <= this is a named coll, there's no file, don't bother
looking for it

[coll x.txt] & [coll x.txt 1] <= the one to the left loads the file, the
one to the right shares the data & doesn't look for the file because it
doesn't need to.

This 2nd argument for coll was introduced in Max 4.0.8

Most of the objects in cyclone are outdated to Max 4.0 and not to some
later version of Max 4 as was assumed sometimes - you can find descriptions
of the cyclone library as "clones from max 4.5" but that is not true,
probably that description was made by the time Max 4.5 was around and
people were just assuming it to be true, but it's not.

It's funny how when cyclone 0.1 alpha 1 comes out, it's already outdated,
cause it was released when Max 4.1 had just been made available (like a
week or 2 before).

Therefore, cyclone's [coll] was outdated since version 0.1 alpha01, and it
just kept outdated until the original author abandoned it (in version 0.1
alpha 55)

Well, enough anecdotes... back to cyclone's current development

The optional 2nd argument was introduced in Pd-l2ork (I don't know when),
and ported to cyclone in the version "cyclone 0.2 beta1". Nonetheless, it
is now removed from the latest state: "cyclone 0.2 beta3" - which is in
deken for windows, and cyclone 0.2 beta1 is still available for mac and
linux in deken. One way or another, if you build it from the repository,
you'll get cyclone 0.2 beta3, without the 2nd argument/threaded
functionality.

I can see other details in this version of coll. For some reason, the bang
output on the third outlet (when finishing reading a file) was removed, and
it is only present in the threaded version.

I can also check that this optional argument can come in any order, before
or after the coll name. In the documentation of cyclone 0.2 it is mentioned
that it's supposed to be only as the 2nd argument (btw, even though this is
removed from cyclone 0.2 beta3, it is still mentioned in the
documentation). Anyway, also having it as the 1st argument goes against the
original max's syntax. So I consider that these changes added some relevant
noise to coll's structure.

So, in my opinion, if new things were to be introduced to coll as they
were, it'd would have been good to check its state. I'm sure that if it was
realized it had a missing 2nd argument that the right thing to do would be
to include it and have another way of dealing with the extra functionality,
in a less intrusive way to its original syntax and all.

I think that an additional "flag" is less intrusive for an extra
functionality. Something like "-threaded".

Well, we've been working on updating cyclone, and the major concern is to
update and include missing functionalities, from Max 4.0 up to the latest
version (Max 7.3.1 currently). There are about 60 objects that needed work
in that direction (and now we have only 5 more to go). None of the other
updates raise any issue like coll does, because coll was the only one that
suffered such kind of intervention. So, what are doing with coll?

We've already updated it to include missing functionalities, which is the
2nd argument, a couple of attributes and a couple of extra methods
(renumber2 and insert2). We are also fixing a couple of bugs. One of the
bugs is the bang output on the 3rd inlet, that we put back...

About the threaded version, we're including it kind of as a flag, but in
the max's attribute style way, so "@threaded 1" loads the threaded version,
and this can also be edited with a "threaded" message method.

I still have a couple of other things to reply to regarding the rest of
your message

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Ico Bukvic]

Joining late to the party...

Being the culprit (I wrote the threaded addition to the coll object) I 
am curious--Alexandre, do you mind elaborating how did the threaded 
thing break max-msp compatibility? If you create a coll object without 
the optional arg, you get Max behavior. If you add the optional arg you 
get threaded which theoretically breaks determinacy in favor of avoiding 
dropping samples due to file I/O in the middle of a performance.


Tests in Max that stand out:

Reading and writing coll files while sound is running does not cause 
xruns in Max, whereas in Pd it can depending on the size of the coll 
file and CPU utilization.


You are right in that determinacy is preserved in Max no matter what 
(e.g. read outlet bang outputs immediately after issuing the read 
message in logical time).


Doing Uzi with 100k generated entries into coll object in Max and I get 
guaranteed crashes from these on both 6 and 7.


Best,

Ico


On 1/26/2017 6:51 AM, Alexandre Torres Porres wrote:

oh, I had read that :) - so, same here, with my new help file, no error!

something weird about that help file... don't ask me either

2017-01-25 16:04 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com 
<mailto:lucard...@hotmail.com>>:


/>>But I never tried that, instead I found and obsure
solve, cant remember, it is somewhere at the list archive./


/>yeah, we should find it :)/



It`s here:

https://lists.puredata.info/pipermail/pd-list/2016-09/116245.html
<https://lists.puredata.info/pipermail/pd-list/2016-09/116245.html>


Mensaje telepatico asistido por maquinas.



*From:* Alexandre Torres Porres <por...@gmail.com
<mailto:por...@gmail.com>>
*Sent:* Wednesday, January 25, 2017 2:53 AM
*To:* Lucas Cordiviola
*Cc:* pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>
*Subject:* Re: [PD] [coll] bug


2017-01-24 18:51 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com
<mailto:lucard...@hotmail.com>>:


I though at that time that the problem migth come cuz in the
help there are multiple [coll]  & they all share not having a
name, I thougt that giving some diff names could solve the
help patch problem.


I have many unnamed coll object in my newly written help file, and
it doesn't give that error, so maybe it's not that...


But I never tried that, instead I found and obsure solve, cant
remember, it is somewhere at the list archive.


yeah, we should find it :)




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

oh, I had read that :) - so, same here, with my new help file, no error!

something weird about that help file... don't ask me either

2017-01-25 16:04 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

> *>>But I never tried that, instead I found and obsure solve, cant
> remember, it is somewhere at the list archive.*
>
>
> *>yeah, we should find it :)*
>
>
>
> It`s here:
>
> https://lists.puredata.info/pipermail/pd-list/2016-09/116245.html
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Alexandre Torres Porres <por...@gmail.com>
> *Sent:* Wednesday, January 25, 2017 2:53 AM
> *To:* Lucas Cordiviola
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>
>
>
> 2017-01-24 18:51 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:
>
>>
>> I though at that time that the problem migth come cuz in the help there
>> are multiple [coll]  & they all share not having a name, I thougt that
>> giving some diff names could solve the help patch problem.
>>
>
> I have many unnamed coll object in my newly written help file, and it
> doesn't give that error, so maybe it's not that...
>
>
>>
>> But I never tried that, instead I found and obsure solve, cant remember,
>> it is somewhere at the list archive.
>>
>
> yeah, we should find it :)
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

>>But I never tried that, instead I found and obsure solve, cant remember, it 
>>is somewhere at the list archive.


>yeah, we should find it :)


It`s here:

https://lists.puredata.info/pipermail/pd-list/2016-09/116245.html



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Wednesday, January 25, 2017 2:53 AM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug



2017-01-24 18:51 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

I though at that time that the problem migth come cuz in the help there are 
multiple [coll]  & they all share not having a name, I thougt that giving some 
diff names could solve the help patch problem.

I have many unnamed coll object in my newly written help file, and it doesn't 
give that error, so maybe it's not that...


But I never tried that, instead I found and obsure solve, cant remember, it is 
somewhere at the list archive.

yeah, we should find it :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-01-24 18:51 GMT-02:00 Lucas Cordiviola :

>
> I though at that time that the problem migth come cuz in the help there
> are multiple [coll]  & they all share not having a name, I thougt that
> giving some diff names could solve the help patch problem.
>

I have many unnamed coll object in my newly written help file, and it
doesn't give that error, so maybe it's not that...


>
> But I never tried that, instead I found and obsure solve, cant remember,
> it is somewhere at the list archive.
>

yeah, we should find it :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

> so, again, only issue I have is with the included help file from cyclone 02

I though at that time that the problem migth come cuz in the help there are 
multiple [coll]  & they all share not having a name, I thougt that giving some 
diff names could solve the help patch problem.

But I never tried that, instead I found and obsure solve, cant remember, it is 
somewhere at the list archive.



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 8:41 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug

yeah, I see I have it in the cyclone 02 beta 2 you sent me...

so, again, only issue I have is with the included help file from cyclone 02

I dont get the error with the new help file I wrote from scratch, I dont have 
the issue with the given test file that initiated this thread on the list, I 
can't replicate it by creating the object or anything.

and the threaded functionality works just fine as it should...

Well, like I said, we are working on updating [coll] and we'll reintroduce this 
functionality and see how it goes, but we'll reintroduce it in a different way, 
as the other way did break max msp compatibility

cheers

2017-01-24 18:32 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:


> well, if I still need another dll I'm not sure, I dont think so, but send me 
> that please?



"libgcc_s_dw2-1.dll" is included that pkg.


Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com<mailto:por...@gmail.com>>
Sent: Tuesday, January 24, 2017 8:27 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at<mailto:pd-list@lists.iem.at>
Subject: Re: [PD] [coll] bug



2017-01-24 18:22 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Irrc beta2 also needs "libgcc_s_dw2-1.dll".

And I think both are only for [coll]

Surely theres a diff in the source code.

Surely its a another compile.

I dont think the source code of coll was altered at all, but I just wanted to 
check what was the existing issue with cyclone beta2 that ended up removing the 
threaded function from it in beta3

as I see, I can only replicate the issue with the help file from cyclone 02, 
but not in other patches...

the threaded function also seems to work fine, with no issues, doing what it is 
supposed to do...

well, if I still need another dll I'm not sure, I dont think so, but send me 
that please?

cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

yeah, I see I have it in the cyclone 02 beta 2 you sent me...

so, again, only issue I have is with the included help file from cyclone 02

I dont get the error with the new help file I wrote from scratch, I dont
have the issue with the given test file that initiated this thread on the
list, I can't replicate it by creating the object or anything.

and the threaded functionality works just fine as it should...

Well, like I said, we are working on updating [coll] and we'll reintroduce
this functionality and see how it goes, but we'll reintroduce it in a
different way, as the other way did break max msp compatibility

cheers

2017-01-24 18:32 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

>
> *> well, if I still need another dll I'm not sure, I dont think so, but
> send me that please?*
>
>
>
> “libgcc_s_dw2-1.dll” is included that pkg.
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Alexandre Torres Porres <por...@gmail.com>
> *Sent:* Tuesday, January 24, 2017 8:27 PM
> *To:* Lucas Cordiviola
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>
>
>
> 2017-01-24 18:22 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:
>
>> Irrc beta2 also needs “libgcc_s_dw2-1.dll”.
>>
>> And I think both are only for [coll]
>>
>> Surely theres a diff in the source code.
>>
>> Surely its a another compile.
>>
>
> I dont think the source code of coll was altered at all, but I just wanted
> to check what was the existing issue with cyclone beta2 that ended up
> removing the threaded function from it in beta3
>
> as I see, I can only replicate the issue with the help file from cyclone
> 02, but not in other patches...
>
> the threaded function also seems to work fine, with no issues, doing what
> it is supposed to do...
>
> well, if I still need another dll I'm not sure, I dont think so, but send
> me that please?
>
> cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

> well, if I still need another dll I'm not sure, I dont think so, but send me 
> that please?



"libgcc_s_dw2-1.dll" is included that pkg.


Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 8:27 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug



2017-01-24 18:22 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Irrc beta2 also needs "libgcc_s_dw2-1.dll".

And I think both are only for [coll]

Surely theres a diff in the source code.

Surely its a another compile.

I dont think the source code of coll was altered at all, but I just wanted to 
check what was the existing issue with cyclone beta2 that ended up removing the 
threaded function from it in beta3

as I see, I can only replicate the issue with the help file from cyclone 02, 
but not in other patches...

the threaded function also seems to work fine, with no issues, doing what it is 
supposed to do...

well, if I still need another dll I'm not sure, I dont think so, but send me 
that please?

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

all that is fine, no problem, no error!

2017-01-24 18:26 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

> Try creating a [coll], use it, dont open the help, close your patch &
> close Pd.
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Alexandre Torres Porres <por...@gmail.com>
> *Sent:* Tuesday, January 24, 2017 8:12 PM
> *To:* Lucas Cordiviola
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>
> It is confirmed, I get the error in cyclone beta2  with the help file when
> I close Pd!
>
>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2017-01-24 18:22 GMT-02:00 Lucas Cordiviola :

> Irrc beta2 also needs “libgcc_s_dw2-1.dll”.
>
> And I think both are only for [coll]
>
> Surely theres a diff in the source code.
>
> Surely its a another compile.
>

I dont think the source code of coll was altered at all, but I just wanted
to check what was the existing issue with cyclone beta2 that ended up
removing the threaded function from it in beta3

as I see, I can only replicate the issue with the help file from cyclone
02, but not in other patches...

the threaded function also seems to work fine, with no issues, doing what
it is supposed to do...

well, if I still need another dll I'm not sure, I dont think so, but send
me that please?

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Try creating a [coll], use it, dont open the help, close your patch & close Pd.


Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 8:12 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug

It is confirmed, I get the error in cyclone beta2  with the help file when I 
close Pd!



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Irrc beta2 also needs "libgcc_s_dw2-1.dll".

And I think both are only for [coll]

Surely theres a diff in the source code.

Surely its a another compile.

Keep in mind that if you compile those olds, you will end up needing 
"pthreadGC-3.dll"  instead of "pthreadGC2.dll" because GC-3 is the newer and 
that one comes with your mingws.



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 8:07 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug

so, the only difference from beta1 and beta2 is that the pthread .dll is 
already included in in beta2, right?

thanks

2017-01-24 17:52 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Here goes the old cyclones:


http://lucarda.com.ar/x/alex-cyclone-past-editions.zip



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com<mailto:por...@gmail.com>>
Sent: Tuesday, January 24, 2017 6:18 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at<mailto:pd-list@lists.iem.at>

Subject: Re: [PD] [coll] bug

great, please send me both 01 and 02 ;)

2017-01-24 16:12 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Hi Alex,

Well 0.2 beta1 had the threaded coll, and there were no problems, or they 
didn`t show up. (problem here was that pthreadGC2.dll was not included in the 
deken pkg, but most people that had Pd-extended installed already had that .dll 
)

Then Fred recompiled beta2 (only for windows?) which had other 3th party .dll 
deps.

Here where problems.

Then beta3 had coll with no threading option.

I can send you both beta1 & 2.

Salutti,
Lucarda.



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com<mailto:por...@gmail.com>>
Sent: Tuesday, January 24, 2017 5:37 PM
To: Lucas Cordiviola; oliver
Cc: Christof Ressi; pd-list@lists.iem.at<mailto:pd-list@lists.iem.at>
Subject: Re: [PD] [coll] bug



2016-09-20 16:12 GMT-03:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Ops,

I'm getting the error but only when opening the help patch. Not if using with 
or without the threaded option.

Testing with beta 2.

We should check the help patch.


Wow, now I tried the help file from "cyclone 02" with the [coll] version we 
have and I finally could replicate the bug and issue!

So this probably didn't happen before cause we have a new help file...

let me point it all out objectively:

- tested the given test patch in our threaded version of coll and in Purr Data 
(which carries the old threaded version of coll): No Problems!

- tested both of these threaded coll versions with their respective help files, 
no issues.

- tested the help file from cyclone 02 with the threaded version and got the 
issue!!! Thus, the issue only presented itself with the help file included in 
cyclone 0.2

- I even tested the problematic help patch by opening it in Purr Data, but 
couldn't replicate the error... so, even when it comes up, it's not that 
consistent.

This needs further investigation of course, but I can deduce that the threaded 
version isn't as problematic in windows as I thought so, doesnt seem like a big 
deal. It doesn't come up all of the time, and when it does it only happens when 
you close Pd, which can be annoying, but doesn't seem to really affect patching 
or anything...

well, I'm sorry that this feature was removed from windows in deken. I'll try 
to build it from beta02 and check this more throughly... but anyone who was 
having problems, please try Purr Data as I said, and see what comes up.

ps. - We are working on an update of [coll] and should include back the 
threaded functionality for windows too. But not in the same way I must say! The 
way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max msp 
compatibility and we consider that to be an issue - as we consider that extra 
features introduced in cyclone should not break max/msp compatibility.
- We are including it now as an extra attribute and that should be alsio 
included in Pd-l2ork/Purr Data as soon as we have a final release.

cheers


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

It is confirmed, I get the error in cyclone beta2  with the help file when
I close Pd!

2017-01-24 18:07 GMT-02:00 Alexandre Torres Porres <por...@gmail.com>:

> so, the only difference from beta1 and beta2 is that the pthread .dll is
> already included in in beta2, right?
>
> thanks
>
> 2017-01-24 17:52 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:
>
>> Here goes the old cyclones:
>>
>>
>> http://lucarda.com.ar/x/alex-cyclone-past-editions.zip
>>
>>
>> Mensaje telepatico asistido por maquinas.
>>
>>
>> --
>> *From:* Alexandre Torres Porres <por...@gmail.com>
>> *Sent:* Tuesday, January 24, 2017 6:18 PM
>> *To:* Lucas Cordiviola
>> *Cc:* pd-list@lists.iem.at
>>
>> *Subject:* Re: [PD] [coll] bug
>>
>> great, please send me both 01 and 02 ;)
>>
>> 2017-01-24 16:12 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:
>>
>>> Hi Alex,
>>>
>>> Well 0.2 beta1 had the threaded coll, and there were no problems, or
>>> they didn`t show up. (problem here was that pthreadGC2.dll was not
>>> included in the deken pkg, but most people that had Pd-extended installed
>>> already had that .dll )
>>>
>>> Then Fred recompiled beta2 (only for windows?) which had other 3th party
>>> .dll deps.
>>>
>>> Here where problems.
>>>
>>> Then beta3 had coll with no threading option.
>>>
>>> I can send you both beta1 & 2.
>>>
>>> Salutti,
>>> Lucarda.
>>>
>>>
>>> Mensaje telepatico asistido por maquinas.
>>>
>>>
>>> --
>>> *From:* Alexandre Torres Porres <por...@gmail.com>
>>> *Sent:* Tuesday, January 24, 2017 5:37 PM
>>> *To:* Lucas Cordiviola; oliver
>>> *Cc:* Christof Ressi; pd-list@lists.iem.at
>>> *Subject:* Re: [PD] [coll] bug
>>>
>>>
>>>
>>> 2016-09-20 16:12 GMT-03:00 Lucas Cordiviola <lucard...@hotmail.com>:
>>>
>>>> Ops,
>>>>
>>>> I'm getting the error but only when opening the help patch. Not if
>>>> using with or without the threaded option.
>>>>
>>>> Testing with beta 2.
>>>>
>>>> We should check the help patch.
>>>>
>>>
>>>
>>> Wow, now I tried the help file from "cyclone 02" with the [coll] version
>>> we have and I finally could replicate the bug and issue!
>>>
>>> So this probably didn't happen before cause we have a new help file...
>>>
>>> let me point it all out objectively:
>>>
>>> - tested the given test patch in our threaded version of coll and in
>>> Purr Data (which carries the old threaded version of coll): No Problems!
>>>
>>> - tested both of these threaded coll versions with their respective help
>>> files, no issues.
>>>
>>> - *tested the help file from cyclone 02 with the threaded version and
>>> got the issue!!!* Thus, the issue only presented itself with the help
>>> file included in cyclone 0.2
>>>
>>> - I even tested the problematic help patch by opening it in Purr Data,
>>> but couldn't replicate the error... so, even when it comes up, it's not
>>> that consistent.
>>>
>>> This needs further investigation of course, but I can deduce that the
>>> threaded version isn't as problematic in windows as I thought so, doesnt
>>> seem like a big deal. It doesn't come up all of the time, and when it does
>>> it only happens when you close Pd, which can be annoying, but doesn't seem
>>> to really affect patching or anything...
>>>
>>> well, I'm sorry that this feature was removed from windows in deken.
>>> I'll try to build it from beta02 and check this more throughly... but
>>> anyone who was having problems, please try Purr Data as I said, and see
>>> what comes up.
>>>
>>> ps. - We are working on an update of [coll] and should include back the
>>> threaded functionality for windows too. But not in the same way I must say!
>>> The way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max
>>> msp compatibility and we consider that to be an issue - as we consider that
>>> extra features introduced in cyclone should not break max/msp compatibility.
>>> - We are including it now as an extra attribute and that should be alsio
>>> included in Pd-l2ork/Purr Data as soon as we have a final release.
>>>
>>> cheers
>>>
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

so, the only difference from beta1 and beta2 is that the pthread .dll is
already included in in beta2, right?

thanks

2017-01-24 17:52 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

> Here goes the old cyclones:
>
>
> http://lucarda.com.ar/x/alex-cyclone-past-editions.zip
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Alexandre Torres Porres <por...@gmail.com>
> *Sent:* Tuesday, January 24, 2017 6:18 PM
> *To:* Lucas Cordiviola
> *Cc:* pd-list@lists.iem.at
>
> *Subject:* Re: [PD] [coll] bug
>
> great, please send me both 01 and 02 ;)
>
> 2017-01-24 16:12 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:
>
>> Hi Alex,
>>
>> Well 0.2 beta1 had the threaded coll, and there were no problems, or they
>> didn`t show up. (problem here was that pthreadGC2.dll was not included
>> in the deken pkg, but most people that had Pd-extended installed already
>> had that .dll )
>>
>> Then Fred recompiled beta2 (only for windows?) which had other 3th party
>> .dll deps.
>>
>> Here where problems.
>>
>> Then beta3 had coll with no threading option.
>>
>> I can send you both beta1 & 2.
>>
>> Salutti,
>> Lucarda.
>>
>>
>> Mensaje telepatico asistido por maquinas.
>>
>>
>> ----------
>> *From:* Alexandre Torres Porres <por...@gmail.com>
>> *Sent:* Tuesday, January 24, 2017 5:37 PM
>> *To:* Lucas Cordiviola; oliver
>> *Cc:* Christof Ressi; pd-list@lists.iem.at
>> *Subject:* Re: [PD] [coll] bug
>>
>>
>>
>> 2016-09-20 16:12 GMT-03:00 Lucas Cordiviola <lucard...@hotmail.com>:
>>
>>> Ops,
>>>
>>> I'm getting the error but only when opening the help patch. Not if using
>>> with or without the threaded option.
>>>
>>> Testing with beta 2.
>>>
>>> We should check the help patch.
>>>
>>
>>
>> Wow, now I tried the help file from "cyclone 02" with the [coll] version
>> we have and I finally could replicate the bug and issue!
>>
>> So this probably didn't happen before cause we have a new help file...
>>
>> let me point it all out objectively:
>>
>> - tested the given test patch in our threaded version of coll and in Purr
>> Data (which carries the old threaded version of coll): No Problems!
>>
>> - tested both of these threaded coll versions with their respective help
>> files, no issues.
>>
>> - *tested the help file from cyclone 02 with the threaded version and
>> got the issue!!!* Thus, the issue only presented itself with the help
>> file included in cyclone 0.2
>>
>> - I even tested the problematic help patch by opening it in Purr Data,
>> but couldn't replicate the error... so, even when it comes up, it's not
>> that consistent.
>>
>> This needs further investigation of course, but I can deduce that the
>> threaded version isn't as problematic in windows as I thought so, doesnt
>> seem like a big deal. It doesn't come up all of the time, and when it does
>> it only happens when you close Pd, which can be annoying, but doesn't seem
>> to really affect patching or anything...
>>
>> well, I'm sorry that this feature was removed from windows in deken. I'll
>> try to build it from beta02 and check this more throughly... but anyone who
>> was having problems, please try Purr Data as I said, and see what comes up.
>>
>> ps. - We are working on an update of [coll] and should include back the
>> threaded functionality for windows too. But not in the same way I must say!
>> The way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max
>> msp compatibility and we consider that to be an issue - as we consider that
>> extra features introduced in cyclone should not break max/msp compatibility.
>> - We are including it now as an extra attribute and that should be alsio
>> included in Pd-l2ork/Purr Data as soon as we have a final release.
>>
>> cheers
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Here goes the old cyclones:


http://lucarda.com.ar/x/alex-cyclone-past-editions.zip



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 6:18 PM
To: Lucas Cordiviola
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug

great, please send me both 01 and 02 ;)

2017-01-24 16:12 GMT-02:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Hi Alex,

Well 0.2 beta1 had the threaded coll, and there were no problems, or they 
didn`t show up. (problem here was that pthreadGC2.dll was not included in the 
deken pkg, but most people that had Pd-extended installed already had that .dll 
)

Then Fred recompiled beta2 (only for windows?) which had other 3th party .dll 
deps.

Here where problems.

Then beta3 had coll with no threading option.

I can send you both beta1 & 2.

Salutti,
Lucarda.



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com<mailto:por...@gmail.com>>
Sent: Tuesday, January 24, 2017 5:37 PM
To: Lucas Cordiviola; oliver
Cc: Christof Ressi; pd-list@lists.iem.at<mailto:pd-list@lists.iem.at>
Subject: Re: [PD] [coll] bug



2016-09-20 16:12 GMT-03:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Ops,

I'm getting the error but only when opening the help patch. Not if using with 
or without the threaded option.

Testing with beta 2.

We should check the help patch.


Wow, now I tried the help file from "cyclone 02" with the [coll] version we 
have and I finally could replicate the bug and issue!

So this probably didn't happen before cause we have a new help file...

let me point it all out objectively:

- tested the given test patch in our threaded version of coll and in Purr Data 
(which carries the old threaded version of coll): No Problems!

- tested both of these threaded coll versions with their respective help files, 
no issues.

- tested the help file from cyclone 02 with the threaded version and got the 
issue!!! Thus, the issue only presented itself with the help file included in 
cyclone 0.2

- I even tested the problematic help patch by opening it in Purr Data, but 
couldn't replicate the error... so, even when it comes up, it's not that 
consistent.

This needs further investigation of course, but I can deduce that the threaded 
version isn't as problematic in windows as I thought so, doesnt seem like a big 
deal. It doesn't come up all of the time, and when it does it only happens when 
you close Pd, which can be annoying, but doesn't seem to really affect patching 
or anything...

well, I'm sorry that this feature was removed from windows in deken. I'll try 
to build it from beta02 and check this more throughly... but anyone who was 
having problems, please try Purr Data as I said, and see what comes up.

ps. - We are working on an update of [coll] and should include back the 
threaded functionality for windows too. But not in the same way I must say! The 
way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max msp 
compatibility and we consider that to be an issue - as we consider that extra 
features introduced in cyclone should not break max/msp compatibility.
- We are including it now as an extra attribute and that should be alsio 
included in Pd-l2ork/Purr Data as soon as we have a final release.

cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

great, please send me both 01 and 02 ;)

2017-01-24 16:12 GMT-02:00 Lucas Cordiviola <lucard...@hotmail.com>:

> Hi Alex,
>
> Well 0.2 beta1 had the threaded coll, and there were no problems, or they
> didn`t show up. (problem here was that pthreadGC2.dll was not included in
> the deken pkg, but most people that had Pd-extended installed already had
> that .dll )
>
> Then Fred recompiled beta2 (only for windows?) which had other 3th party
> .dll deps.
>
> Here where problems.
>
> Then beta3 had coll with no threading option.
>
> I can send you both beta1 & 2.
>
> Salutti,
> Lucarda.
>
>
> Mensaje telepatico asistido por maquinas.
>
>
> --
> *From:* Alexandre Torres Porres <por...@gmail.com>
> *Sent:* Tuesday, January 24, 2017 5:37 PM
> *To:* Lucas Cordiviola; oliver
> *Cc:* Christof Ressi; pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>
>
>
> 2016-09-20 16:12 GMT-03:00 Lucas Cordiviola <lucard...@hotmail.com>:
>
>> Ops,
>>
>> I'm getting the error but only when opening the help patch. Not if using
>> with or without the threaded option.
>>
>> Testing with beta 2.
>>
>> We should check the help patch.
>>
>
>
> Wow, now I tried the help file from "cyclone 02" with the [coll] version
> we have and I finally could replicate the bug and issue!
>
> So this probably didn't happen before cause we have a new help file...
>
> let me point it all out objectively:
>
> - tested the given test patch in our threaded version of coll and in Purr
> Data (which carries the old threaded version of coll): No Problems!
>
> - tested both of these threaded coll versions with their respective help
> files, no issues.
>
> - *tested the help file from cyclone 02 with the threaded version and got
> the issue!!!* Thus, the issue only presented itself with the help file
> included in cyclone 0.2
>
> - I even tested the problematic help patch by opening it in Purr Data, but
> couldn't replicate the error... so, even when it comes up, it's not that
> consistent.
>
> This needs further investigation of course, but I can deduce that the
> threaded version isn't as problematic in windows as I thought so, doesnt
> seem like a big deal. It doesn't come up all of the time, and when it does
> it only happens when you close Pd, which can be annoying, but doesn't seem
> to really affect patching or anything...
>
> well, I'm sorry that this feature was removed from windows in deken. I'll
> try to build it from beta02 and check this more throughly... but anyone who
> was having problems, please try Purr Data as I said, and see what comes up.
>
> ps. - We are working on an update of [coll] and should include back the
> threaded functionality for windows too. But not in the same way I must say!
> The way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max
> msp compatibility and we consider that to be an issue - as we consider that
> extra features introduced in cyclone should not break max/msp compatibility.
> - We are including it now as an extra attribute and that should be alsio
> included in Pd-l2ork/Purr Data as soon as we have a final release.
>
> cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Hi Alex,

Well 0.2 beta1 had the threaded coll, and there were no problems, or they 
didn`t show up. (problem here was that pthreadGC2.dll was not included in the 
deken pkg, but most people that had Pd-extended installed already had that .dll 
)

Then Fred recompiled beta2 (only for windows?) which had other 3th party .dll 
deps.

Here where problems.

Then beta3 had coll with no threading option.

I can send you both beta1 & 2.

Salutti,
Lucarda.



Mensaje telepatico asistido por maquinas.



From: Alexandre Torres Porres <por...@gmail.com>
Sent: Tuesday, January 24, 2017 5:37 PM
To: Lucas Cordiviola; oliver
Cc: Christof Ressi; pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug



2016-09-20 16:12 GMT-03:00 Lucas Cordiviola 
<lucard...@hotmail.com<mailto:lucard...@hotmail.com>>:

Ops,

I'm getting the error but only when opening the help patch. Not if using with 
or without the threaded option.

Testing with beta 2.

We should check the help patch.


Wow, now I tried the help file from "cyclone 02" with the [coll] version we 
have and I finally could replicate the bug and issue!

So this probably didn't happen before cause we have a new help file...

let me point it all out objectively:

- tested the given test patch in our threaded version of coll and in Purr Data 
(which carries the old threaded version of coll): No Problems!

- tested both of these threaded coll versions with their respective help files, 
no issues.

- tested the help file from cyclone 02 with the threaded version and got the 
issue!!! Thus, the issue only presented itself with the help file included in 
cyclone 0.2

- I even tested the problematic help patch by opening it in Purr Data, but 
couldn't replicate the error... so, even when it comes up, it's not that 
consistent.

This needs further investigation of course, but I can deduce that the threaded 
version isn't as problematic in windows as I thought so, doesnt seem like a big 
deal. It doesn't come up all of the time, and when it does it only happens when 
you close Pd, which can be annoying, but doesn't seem to really affect patching 
or anything...

well, I'm sorry that this feature was removed from windows in deken. I'll try 
to build it from beta02 and check this more throughly... but anyone who was 
having problems, please try Purr Data as I said, and see what comes up.

ps. - We are working on an update of [coll] and should include back the 
threaded functionality for windows too. But not in the same way I must say! The 
way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max msp 
compatibility and we consider that to be an issue - as we consider that extra 
features introduced in cyclone should not break max/msp compatibility.
- We are including it now as an extra attribute and that should be alsio 
included in Pd-l2ork/Purr Data as soon as we have a final release.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-20 16:12 GMT-03:00 Lucas Cordiviola :

> Ops,
>
> I'm getting the error but only when opening the help patch. Not if using
> with or without the threaded option.
>
> Testing with beta 2.
>
> We should check the help patch.
>


Wow, now I tried the help file from "cyclone 02" with the [coll] version we
have and I finally could replicate the bug and issue!

So this probably didn't happen before cause we have a new help file...

let me point it all out objectively:

- tested the given test patch in our threaded version of coll and in Purr
Data (which carries the old threaded version of coll): No Problems!

- tested both of these threaded coll versions with their respective help
files, no issues.

- *tested the help file from cyclone 02 with the threaded version and got
the issue!!!* Thus, the issue only presented itself with the help file
included in cyclone 0.2

- I even tested the problematic help patch by opening it in Purr Data, but
couldn't replicate the error... so, even when it comes up, it's not that
consistent.

This needs further investigation of course, but I can deduce that the
threaded version isn't as problematic in windows as I thought so, doesnt
seem like a big deal. It doesn't come up all of the time, and when it does
it only happens when you close Pd, which can be annoying, but doesn't seem
to really affect patching or anything...

well, I'm sorry that this feature was removed from windows in deken. I'll
try to build it from beta02 and check this more throughly... but anyone who
was having problems, please try Purr Data as I said, and see what comes up.

ps. - We are working on an update of [coll] and should include back the
threaded functionality for windows too. But not in the same way I must say!
The way it was introduced in Pd-l2ork/Purr Data and cyclone 0.2 broke max
msp compatibility and we consider that to be an issue - as we consider that
extra features introduced in cyclone should not break max/msp compatibility.
- We are including it now as an extra attribute and that should be alsio
included in Pd-l2ork/Purr Data as soon as we have a final release.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

Hi, hey... now I got a windows machine, so I tried to test this! It's
windows 10 64 bits btw

but well... I cant get the old coll from cyclone02 beta cause it is gone
from deken...

i guess I could build it, but i still dont know how to do that in windows...

anyway, so first thing I did is I tried Purr Data, which has the same
object version that was in cyclone 0.2 and I dont get that problem.

so those of you who want to use the coll object with the threaded version
working in windows, you can try Purr Data!

if anyone has cyclone 02 beta 1 or 2 for windows to send me, it'd be
cool... otherwise I have to learn how to compile

Another thing I did is I tried an experimental prealpha release from our
git, that was available for windows, that issue didnt come up either, but
it has other issues cause it's going through some surgery and updates -
hence, I just suggest you all try Purr Data!

cheers


2016-09-16 18:22 GMT-03:00 oliver :

> hi, list !
>
> i recently ran into a bug when i used the "coll" object from the BETA
> cyclone library.
>
> simply put: when i create a coll object and quit PD, it throws a Microsoft
> Visual C++ Runtime Error (see image).
>
> example patch is attached.
>
>
> the object seems to work though, as long as PD is running. only the 3rd
> outlet (bang when file read) doesn't work.
>
>
> i downloaded the cyclone 0.2 beta package with deken.
> the older pd-extended version (also from deken) works fine.
>
>
> PD 0.47-2, Windows 7 64 bit
>
>
> did anybody experience this as well ?
>
>
>
> best
>
> oliver
>
>
> --
> 
> /// http://pendler.klingt.org //
> \\\ http://oliver.klingt.org  \\
> 
>  LIVE-BUILDER (music improvisation tool): \\
> // http://tinyurl.com/qaohv35 //
> 
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Ok,
I`ve already said what I could say.



Mensaje telepatico asistido por maquinas.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-21 12:55 GMT-03:00 Fred Jan Kraan :

> I only try to keep a stable, backward compatible version
> available.
>

yeah, and it makes perfect sense then to just take it out if it is unstable.

as I said in this thread, me, derek and matt have been checking and working
on existing issues with cyclone - nothing made available yet. Fred Jan's
repo actually refers to our repo as the "active development" one, which is
https://github.com/porres/pd-cyclone/

We can try and see about this error, so whoever is willing to collaborate
sending examples and test reports, we could use this channel
https://github.com/porres/pd-cyclone/issues

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Fred Jan Kraan]

Hi Lucas,


> Can you test?
> 
> This worked ok with beta2, probably it will work on your new beta4.
>  
Don't confuse my attempt to produce a stable cyclone with maintenance in
the sense of adding features to its objects, others have appropriated
that role. I only try to keep a stable, backward compatible version
available.
> 
> Salutti,
> Lucarda.

Greetings,

Fred Jan
> 
> 
> Mensaje telepatico asistido por maquinas.
> 
> 
> 
> *From:* Pd-list <pd-list-boun...@lists.iem.at> on behalf of Lucas
> Cordiviola <lucard...@hotmail.com>
> *Sent:* Tuesday, September 20, 2016 7:12 PM
> *To:* Fred Jan Kraan; Christof Ressi; por...@gmail.com
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>  
> 
> Ops,
> 
> I'm getting the error but only when opening the help patch. Not if using
> with or without the threaded option.
> 
> Testing with beta 2.
> 
> We should check the help patch.
> 
> 
> 
> 
> Mensaje telepatico asistido por maquinas.
> 
> 
> 
> *From:* Fred Jan Kraan <fjkr...@xs4all.nl>
> *Sent:* Tuesday, September 20, 2016 5:53 PM
> *To:* Lucas Cordiviola; Christof Ressi
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] [coll] bug
>  
> 
> 
> On 2016-09-20 07:28 PM, Lucas Cordiviola wrote:
>> @Christof
>> 
>> 
>> Thanx for the feedback.
>> 
>> 
>> @Fred
>> 
>> 
>> Thanx for the fix.
>> 
>> 
>> I was unable to get the error on beta 2, tested with win7-32, win8.1-64
>> and win10-64 (virtual machine). Seems to be only on win7-64 (I didn`t
>> test it).
> And Windows 10 32-bit, that is where I tested it and getting the same
> error. If I can't get it working properly on my build machine, I
> shouldn't distribute it.
>>  
>> Dan has mentioned something cool that could be used for threading:
>> 
>> https://lists.puredata.info/pipermail/pd-list/2016-09/116233.html
>> 
> What I expect is that it isn't the threading per se that causes the
> error, just the weird situation with the varying DLLs that have to be
> provided. I didn't like that at all.
>> 
>> may be in the future.
>> 
>> 
>> Salutti,
>> 
>> Lucarda.
> 
> Greetings,
> 
> Fred Jan
>> 
>> 
>> 
>> 
>> 
>> Mensaje telepatico asistido por maquinas.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

so, finally checking [coll], the very last object I'm checking from all
cyclone objects, this has taken 7 months of my life so far. And, as usual,
I'm finding a few issues.

2016-09-17 4:55 GMT-03:00 Derek Kwan :

> that third outlet seems to work fine to me.
>

Well, it's not working here either, so I'm confirming the bug. I'm on Mac
OS, so it works only on Linux maybe.

I've noticed something else. There's a 2nd argument in Max coll since the
time of Max 4 - it's a number flag for not loading a given file. This was
never implemented in cyclone, and would come in conflict with the thread
argument idea (which could have been introduced with a flag/attribute
instead of an argument).

well, coll has dozens of messages to check and test, I'll still spend a
couple of weeks on it.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

@Christof


Thanx for the feedback.


@Fred


Thanx for the fix.


I was unable to get the error on beta 2, tested with win7-32, win8.1-64 and 
win10-64 (virtual machine). Seems to be only on win7-64 (I didn`t test it).


Dan has mentioned something cool that could be used for threading:


https://lists.puredata.info/pipermail/pd-list/2016-09/116233.html


may be in the future.


Salutti,

Lucarda.





Mensaje telepatico asistido por maquinas.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Fred Jan Kraan]

Hi Christof,

> Hi, I've tried your binaries and I get the runtime error on closing Pd even 
> if I have only loaded [coll] without actually using it.
> 
> Tested with Pd 0.47.1, Windows 7.

But did you test with coll 0.2beta2 of 0.2beta3 ? Only the latter
reports a version number in the console at log level 4.

The beta3 version doesn't produce the runtime error on closing Pd, at
least on my system: Pd 0.47.1, Windows 10.
> 
> Christof

Greetings,

Fred Jan
>  
>  
> 
> Gesendet: Montag, 19. September 2016 um 03:42 Uhr
> Von: "Lucas Cordiviola" <lucard...@hotmail.com>
> An: "Fred Jan Kraan" <fjkr...@xs4all.nl>
> Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
> Betreff: Re: [PD] [coll] bug
> 
>  
> 
> Hi Fred, list,
>  
>  
>  
>  
> 
>> There is a cyclone-v0.2beta3 for Windows available. The error message is
>  
>  
> 
>> gone (tested), but there is no thread functionality anymore. 
>  
>  
> 
>  
> Are you sure about cutting thread functionality?
>  
> This seems to happened only to Oliver, and he had a bad patch:
>  
> https://lists.puredata.info/pipermail/pd-list/2016-09/116218.html
>  
> I have no idea how he messed that colltest patch. Did that patch was used for 
> your tests?
> I'm on win 8.1 and couldn't replicate that error in normal circumstances.
> What was not working was the bang on the 3th outlet when finishing readings.
>  
> In case anyone reading this is willing to test and confirm I put 
> “cyclone-v0.2beta2” with thread functionality here:
>  
> http://lucarda.com.ar/x/cyclone-v0.2beta2-(Windows-i386-32)(Sources)-externals.zip[http://lucarda.com.ar/x/cyclone-v0.2beta2-(Windows-i386-32)(Sources)-externals.zip]
>  
> Basically create a [coll] and do some stuff, then close the patch and exit 
> Pd, or open coll`s help, do some stuff and then exit Pd.
> Report if you get or not errors when exiting Pd (I didn't get those errors).
>  
>  
> Salutti,
> Lucarda.
>  
>  
>   
>  
>  
> 
> Mensaje telepatico asistido por maquinas. 
> 
> ----------------
> 
> From: Pd-list <pd-list-boun...@lists.iem.at> on behalf of Fred Jan Kraan 
> <fjkr...@xs4all.nl>
> Sent: Saturday, September 17, 2016 11:19 AM
> To: oliver
> Cc: pd-list@lists.iem.at
> Subject: Re: [PD] [coll] bug
>  
> Hi Oliver,
> 
> There is a cyclone-v0.2beta3 for Windows available. The error message is
> gone (tested), but there is no thread functionality anymore.
> 
> Greetings,
> 
> Fred Jan
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]___
>  Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Christof Ressi]

Hi, I've tried your binaries and I get the runtime error on closing Pd even if 
I have only loaded [coll] without actually using it.

Tested with Pd 0.47.1, Windows 7.

Christof
 
 

Gesendet: Montag, 19. September 2016 um 03:42 Uhr
Von: "Lucas Cordiviola" <lucard...@hotmail.com>
An: "Fred Jan Kraan" <fjkr...@xs4all.nl>
Cc: "pd-list@lists.iem.at" <pd-list@lists.iem.at>
Betreff: Re: [PD] [coll] bug

 

Hi Fred, list,
 
 
 
 

>There is a cyclone-v0.2beta3 for Windows available. The error message is
 
 

>gone (tested), but there is no thread functionality anymore. 
 
 

 
Are you sure about cutting thread functionality?
 
This seems to happened only to Oliver, and he had a bad patch:
 
https://lists.puredata.info/pipermail/pd-list/2016-09/116218.html
 
I have no idea how he messed that colltest patch. Did that patch was used for 
your tests?
I'm on win 8.1 and couldn't replicate that error in normal circumstances.
What was not working was the bang on the 3th outlet when finishing readings.
 
In case anyone reading this is willing to test and confirm I put 
“cyclone-v0.2beta2” with thread functionality here:
 
http://lucarda.com.ar/x/cyclone-v0.2beta2-(Windows-i386-32)(Sources)-externals.zip[http://lucarda.com.ar/x/cyclone-v0.2beta2-(Windows-i386-32)(Sources)-externals.zip]
 
Basically create a [coll] and do some stuff, then close the patch and exit Pd, 
or open coll`s help, do some stuff and then exit Pd.
Report if you get or not errors when exiting Pd (I didn't get those errors).
 
 
Salutti,
Lucarda.
 
 
  
 
 

Mensaje telepatico asistido por maquinas. 



From: Pd-list <pd-list-boun...@lists.iem.at> on behalf of Fred Jan Kraan 
<fjkr...@xs4all.nl>
Sent: Saturday, September 17, 2016 11:19 AM
To: oliver
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug
 
Hi Oliver,

There is a cyclone-v0.2beta3 for Windows available. The error message is
gone (tested), but there is no thread functionality anymore.

Greetings,

Fred Jan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]___
 Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Lucas Cordiviola]

Hi Fred, list,



>There is a cyclone-v0.2beta3 for Windows available. The error message is

>gone (tested), but there is no thread functionality anymore.

Are you sure about cutting thread functionality?

This seems to happened only to Oliver, and he had a bad patch:

https://lists.puredata.info/pipermail/pd-list/2016-09/116218.html

I have no idea how he messed that colltest patch. Did that patch was used for 
your tests?
I'm on win 8.1 and couldn't replicate that error in normal circumstances.
What was not working was the bang on the 3th outlet when finishing readings.

In case anyone reading this is willing to test and confirm I put 
"cyclone-v0.2beta2" with thread functionality here:

http://lucarda.com.ar/x/cyclone-v0.2beta2-(Windows-i386-32)(Sources)-externals.zip

Basically create a [coll] and do some stuff, then close the patch and exit Pd, 
or open coll`s help, do some stuff and then exit Pd.
Report if you get or not errors when exiting Pd (I didn't get those errors).


Salutti,
Lucarda.






Mensaje telepatico asistido por maquinas.



From: Pd-list <pd-list-boun...@lists.iem.at> on behalf of Fred Jan Kraan 
<fjkr...@xs4all.nl>
Sent: Saturday, September 17, 2016 11:19 AM
To: oliver
Cc: pd-list@lists.iem.at
Subject: Re: [PD] [coll] bug

Hi Oliver,

There is a cyclone-v0.2beta3 for Windows available. The error message is
gone (tested), but there is no thread functionality anymore.

Greetings,

Fred Jan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Marco Matteo Markidis]

IMHO, thread functionality is one of the milestone of [coll]
implementation. Please, don't trash it.

Best.

2016-09-18 9:43 GMT+02:00 Ivica Bukvic :

> Instead of outright removing the feature for all platforms when it works
> on 2 out of 3 them, you could disable building it on Windows as it is very
> much useful on other platforms that support POSIX threads. There are
> wrappers out there for this purpose, and IIRC differences between native
> Windows threads and pthreads are not that great. So a fix, while it is
> likely more time-consuming than deleting the code, in this case should not
> be that much harder to do.
>
> Best,
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
> On Sep 18, 2016 08:15, "Alexandre Torres Porres"  wrote:
>
>> 2016-09-17 11:03 GMT-03:00 Ivica Bukvic :
>>
>>> Is this fix Windows specific or is it gone on all platforms?--
>>>
>> the latest build, 02beta3 has the threaded version gone, but it is only
>> available for windows - though the help file still mentions the thread flag
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Bukvic]

Instead of outright removing the feature for all platforms when it works on
2 out of 3 them, you could disable building it on Windows as it is very
much useful on other platforms that support POSIX threads. There are
wrappers out there for this purpose, and IIRC differences between native
Windows threads and pthreads are not that great. So a fix, while it is
likely more time-consuming than deleting the code, in this case should not
be that much harder to do.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 18, 2016 08:15, "Alexandre Torres Porres"  wrote:

> 2016-09-17 11:03 GMT-03:00 Ivica Bukvic :
>
>> Is this fix Windows specific or is it gone on all platforms?--
>>
> the latest build, 02beta3 has the threaded version gone, but it is only
> available for windows - though the help file still mentions the thread flag
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-17 11:03 GMT-03:00 Ivica Bukvic :

> Is this fix Windows specific or is it gone on all platforms?--
>
the latest build, 02beta3 has the threaded version gone, but it is only
available for windows - though the help file still mentions the thread flag
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-17 5:00 GMT-03:00 Derek Kwan :

> > On first glance, it looks like 0.2beta has pthread stuff that
> > 0.1-alpha55 has...
>
> 0.2beta has pthread stuff that 0.1-alpha55 DOESN'T HAVE, sorry for the typo
>

alpha 55 is the one present in Pd Extended 0.42-5

As I said, alpha 56, present in Pd Extended 0.43-4 doesnt have it either.

So this was either introduced in alpha 57 or 0.2 beta, but now seems to
have been removed from the latest build
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

2016-09-17 20:04 GMT-03:00 oliver :

> will check out purrdata, sound very interesting. but for old patches sake
> i have to stick with cyclone.
>

cyclone IS in Purr Data, so I dont get it ;)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[oliver]

hi,

thank you all for your efforts and your interest in my little problem. 
much appreciated !




Hi Oliver,

There is a cyclone-v0.2beta3 for Windows available. The error message is
gone (tested), but there is no thread functionality anymore.



yep ! that did it ! problem gone !

thanks a bunch, fred jan !



@lucarda:

i tried your approach as well, thanks for your time to deep-check it. 
sure enough this also worked ! i don't know what happened in my patch 
(the line nr. 7 weirdness), since i DIDN'T edit it by hand.


but even then, the third outlet wouldn't output a bang at the succesful 
reading of a file (which is a feature i much appreciate, for keeping 
follow-up things in nice order).


but as i already said: with beta3, [coll] works again as it used to :-)

@ alexandre:

will check out purrdata, sound very interesting. but for old patches 
sake i have to stick with cyclone.


@ marco:

yeah, i did try all possible combinations in coll's creation arguments, 
threaded and not... no difference.



again, thank you all for contributing !

best

oliver



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Fred Jan Kraan]

Hi Oliver,

There is a cyclone-v0.2beta3 for Windows available. The error message is
gone (tested), but there is no thread functionality anymore.

Greetings,

Fred Jan

> hi, list !
> 
> i recently ran into a bug when i used the "coll" object from the BETA
> cyclone library.
> 
> simply put: when i create a coll object and quit PD, it throws a
> Microsoft Visual C++ Runtime Error (see image).
> 
> example patch is attached.
> 
> 
> the object seems to work though, as long as PD is running. only the 3rd
> outlet (bang when file read) doesn't work.
> 
> 
> i downloaded the cyclone 0.2 beta package with deken.
> the older pd-extended version (also from deken) works fine.
> 
> 
> PD 0.47-2, Windows 7 64 bit
> 
> 
> did anybody experience this as well ?
> 
> 
> 
> best
> 
> oliver
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Marco Matteo Markidis]

Hi Oliver,

can you try: [coll  0] , where  is the name
of the file you want to load in coll and 0 starts the non-threaded version
of coll.

Best,

Marco


2016-09-17 10:00 GMT+02:00 Derek Kwan :

> > On first glance, it looks like 0.2beta has pthread stuff that
> > 0.1-alpha55 has...
>
> 0.2beta has pthread stuff that 0.1-alpha55 DOESN'T HAVE, sorry for the typo
>
> Derek
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Derek Kwan]

> On first glance, it looks like 0.2beta has pthread stuff that
> 0.1-alpha55 has...

0.2beta has pthread stuff that 0.1-alpha55 DOESN'T HAVE, sorry for the typo

Derek

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Derek Kwan]

Hello,

Linux checking in. I can't seem to replicate the bug on my computer and
that third outlet seems to work fine to me.

Would that version with pd-extended be the one found on the
puredata.info page (0.1-alpha55)? It says it was included in 0.42.5.

On first glance, it looks like 0.2beta has pthread stuff that
0.1-alpha55 has... in particular the coll_free method (which I'd assume
would be called when PD quits) uses them... I suppose pthread deals with
multithreading? That's about all I know about it... suppose I can do some
reading though =).

Derek

On Sep 16, oliver wrote:
> hi, list !
> 
> i recently ran into a bug when i used the "coll" object from the BETA
> cyclone library.
> 
> simply put: when i create a coll object and quit PD, it throws a Microsoft
> Visual C++ Runtime Error (see image).
> 
> example patch is attached.
> 
> 
> the object seems to work though, as long as PD is running. only the 3rd
> outlet (bang when file read) doesn't work.
> 
> 
> i downloaded the cyclone 0.2 beta package with deken.
> the older pd-extended version (also from deken) works fine.
> 
> 
> PD 0.47-2, Windows 7 64 bit
> 
> 
> did anybody experience this as well ?
> 
> 
> 
> best
> 
> oliver

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Alexandre Torres Porres]

> PD 0.47-2, Windows 7 64 bit
>

you mean pd 0.47-1 right?


> did anybody experience this as well ?
>

i dont have windows to test this

i downloaded the cyclone 0.2 beta package with deken.
> the older pd-extended version (also from deken) works fine.
>

The older pd-extended version available in deken ( cyclone-extendedv0.0) is
version alpha 56, and is the one present in Pd Extended 0.43-4

After that, Fred Jan did release and alpha 57 version and the 0.2 beta
(this one also available in deken).

If I'm not mistaken, the 0.2 beta has a newer version of the coll object
which was actually provided by Ivica from Pd-L2ork.

Unfortunately i dont know the details of what was done, maybe they can help
on that. But it sure looks like this bug was introduced.

I hope other windows users can replicate this bug.

Well, Purr Data is a new thing on the table, it is a branch from Pd-L2ork
being ported to all operating systems. Please try that.

If the changes from Pd-L2ork that were introduced in cyclone 0.2 beta is
the culprit, we should see the same behaviour on Purr Data's [coll]
https://git.purrdata.net/jwilkes/purr-data-binaries

Please try Purr Data for windows, i needs testing, and is the thing that's
about to replace good old extended.

And maybe jonathan, who's taking care of Purr Data can help

Me, Derek and Matt have been checking existing issues with cyclone, but we
haven't got to coll yet

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list