Re: [PD] creb's ramp~ needs a help file

[Dan Wilcox]

I’d say replace C implementations with abstractions if the performance 
difference is negligible. :)

> On Jan 28, 2017, at 5:41 PM, pd-list-requ...@lists.iem.at wrote:
> 
>  I think it could be a good idea and a lot of work to present at least some 
> examples in the help files of how such externals could be modelled within Pd 
> vanilla. Naively I think this could help both newbies and people learning to 
> code externals.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] creb's ramp~ needs a help file

[Ed Kelly via Pd-list]

Yes, I think the documentation is important (shame on me for never finishing 
all my docs). It's just a bit of a shame that we have to document some quite 
redundant functions, but if they make life easier for other patchers then 
that's great. I've made quite a few things in C that could be abstractions for 
example.

Also, there's an annoyance that comes from having to investigate C code from 
abandoned libs, although this is usually not so hard with things like ramp~. I 
think it could be a good idea and a lot of work to present at least some 
examples in the help files of how such externals could be modelled within Pd 
vanilla. Naively I think this could help both newbies and people learning to 
code externals.
xEd
 _-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Saturday, 28 January 2017, 20:48, Alexandre Torres Porres 
 wrote:
 

 
it's one of those objects that is in Pd but could be easily dealt with in Pd 
without the external (...) but it's basically a line~ with an offset, and a 
fixed rate 

 looks like~ cyclone's count~ but much simpler

it just generates a signal ramp with the right characteristics to patch it into 
tabread4~ and playback samples at their original pitch.

or using it with tabread~ then instead pf tabread4~
looks again like count~ as one of its applications is in conjunction with 
index~ (basically tabread~). 

There are quite a lot of externals like this (and some from me) where people 
coded something in C for convenience, but can be easily done in Pd without 
externals.

I know... Pd Extended is filled with things like that, and to make it more of a 
deal, documentation is sometimes bad, when simply non existing.
I'm willing to help this in the forth coming Purr Data, by reorganising it and 
making it better documented
cheers

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

Re: [PD] creb's ramp~ needs a help file

[Alexandre Torres Porres]

>
> it's one of those objects that is in Pd but could be easily dealt with in
> Pd without the external (...) but it's basically a line~ with an offset,
> and a fixed rate
>

 looks like~ cyclone's count~ but much simpler

it just generates a signal ramp with the right characteristics to patch it
> into tabread4~ and playback samples at their original pitch.
>

or using it with tabread~ then instead pf tabread4~

looks again like count~ as one of its applications is in conjunction with
index~ (basically tabread~).


There are quite a lot of externals like this (and some from me) where
> people coded something in C for convenience, but can be easily done in Pd
> without externals.
>

I know... Pd Extended is filled with things like that, and to make it more
of a deal, documentation is sometimes bad, when simply non existing.

I'm willing to help this in the forth coming Purr Data, by reorganising it
and making it better documented

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

Re: [PD] Purr Data rc4

[Lucas Cordiviola]

>>It will ease tests.


>You can open up access to the network in nw.js by removing the following line 
>from nw/package.json:

"chromium-args": "--proxy-server=http://127.0.0.1;,

Right, got it working, it will be fun when the mixed file spec can be tested.

As of "developer tools" being the "natural html editor" I think this needs 
closer look, I have unexpected robot false repairs of good html. Probably is 
better not to do it with the editor.



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]

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] creb's ramp~ needs a help file

[Alexandre Torres Porres]

Thanks, if I'm not mistaken, Fred is taking care of creb now, so maybe he
could work on this help file and include it in a new deken release

cheers

2017-01-28 12:48 GMT-02:00 Ed Kelly :

> ramp~
>
> send it a number and it will generate a ramp~ - effectively a sample
> number to read arrays with something like a phasor~, but it just goes up
> and up.
>
> I just had a look in the C code. In all honesty it's one of those objects
> that is in Pd but could be easily dealt with in Pd without the external. No
> disrespect to Tom Schouten, but it's basically a line~ with an offset, and
> a fixed rate i.e. it just generates a signal ramp with the right
> characteristics to patch it into tabread4~ and playback samples at their
> original pitch. The only exception is that it always starts from a specific
> value sent to the inlet.
>
> There are quite a lot of externals like this (and some from me) where
> people coded something in C for convenience, but can be easily done in Pd
> without externals.
>
> Here's a semi pddp formatted helpfile.
> It's boring.
> Cheers,
> Ed
>
> _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
>
> For *Lone Shark *releases, *Pure Data *software and published *Research*,
> go to http://sharktracks.co.uk
>
>
> On Thursday, 19 January 2017, 0:38, Alexandre Torres Porres <
> por...@gmail.com> wrote:
>
>
> howdy, there's no help file for creb/ramp~
>
> anybody ever used it?
>
> thanks
>
> ___
> 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] Purr Data rc4

[Jonathan Wilkes via Pd-list]

>>Yes, as of “refactoring” I propose starting with the simpler straigth forward 
>>option that you can devise.

>As of “careful consideration” I think first there must be a starting point.




>Is it too soon for opening the internet socket?
>For evaluating potential?
>It will ease tests.
You can open up access to the network in nw.js by removing the following line 
from nw/package.json:"chromium-args": "--proxy-server=http://127.0.0.1;,

If you remove that line then the GUI will make some network requests to Google 
for various 
reasons.  Some of the requests are security-related, and I'm unwilling to set 
various flags in any 
attempt to keep the GUI from talking to Google while leaving net access open.
It's either:a) default Purr Data behavior of no net access in or out for the 
GUI frontendb) remove that line and talk to Google at startup (and possibly at 
other times)
-Jonathan
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] creb's ramp~ needs a help file

[Ed Kelly via Pd-list]

ramp~
send it a number and it will generate a ramp~ - effectively a sample number to 
read arrays with something like a phasor~, but it just goes up and up.
I just had a look in the C code. In all honesty it's one of those objects that 
is in Pd but could be easily dealt with in Pd without the external. No 
disrespect to Tom Schouten, but it's basically a line~ with an offset, and a 
fixed rate i.e. it just generates a signal ramp with the right characteristics 
to patch it into tabread4~ and playback samples at their original pitch. The 
only exception is that it always starts from a specific value sent to the inlet.
There are quite a lot of externals like this (and some from me) where people 
coded something in C for convenience, but can be easily done in Pd without 
externals.

Here's a semi pddp formatted helpfile.It's boring.Cheers,Ed
 _-_-_-_-_-_-_-^-_-_-_-_-_-_-_

For Lone Shark releases, Pure Data software and published Research, go to 
http://sharktracks.co.uk  

On Thursday, 19 January 2017, 0:38, Alexandre Torres Porres 
 wrote:
 

 howdy, there's no help file for creb/ramp~
anybody ever used it?
thanks
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   #N canvas 212 31 559 582 10;
#X obj 9 523 cnv 15 550 20 empty \$0-pddp.cnv.footer empty 20 12 0
14 -228856 -66577 0;
#X obj 9 7 cnv 15 554 54 empty \$0-pddp.cnv.header creb/ramp~ 3 12
0 18 -204280 -1 0;
#X obj 8 263 cnv 3 550 3 empty \$0-pddp.cnv.inlets inlets 8 12 0 13
-228856 -1 0;
#X obj 8 323 cnv 3 550 3 empty \$0-pddp.cnv.outlets outlet 8 12 0 13
-228856 -1 0;
#X obj 8 383 cnv 3 550 3 empty \$0-pddp.cnv.more_info more_info 8 12
0 13 -228856 -1 0;
#X obj 77 283 cnv 17 3 30 empty \$0-pddp.cnv.let.0 0 5 9 0 16 -228856
-162280 0;
#X msg 157 135 \; pd dsp 1;
#X obj 78 343 cnv 17 3 30 empty \$0-pddp.cnv.let.0 0 5 9 0 16 -228856
-162280 0;
#X text 107 342 signal;
#N canvas 308 206 494 344 META 0;
#X text 12 140 HELP_PATCH_AUTHORS "pd meta" information added by Jonathan
Wilkes for Pd version 0.42.;
#X text 12 25 LICENSE GPL v2;
#X text 12 5 KEYWORDS signal;
#X text 12 100 OUTLET_0 signal;
#X text 12 45 DESCRIPTION start a signal ramp to read an array at any
point;
#X text 12 80 INLET_0 control;
#X text 12 120 AUTHOR Tom Schouten;
#X restore 510 524 pd META;
#X text 20 30 description: generates a signal ramp starting from the
float it's presented with.;
#X obj 68 122 ramp~;
#X obj 446 23 import creb;
#X msg 57 93 0;
#X msg 100 92 800;
#X obj 68 144 envrms~;
#X floatatom 68 166 0 0 0 0 - - -;
#X text 107 283 control;
#X text 157 283 - the ramp will start from this value;
#X text 157 342 - a ramp starting from that value;
#X text 105 390 The creb ramp~ object generates a signal to read arrays
using tabread~ or tabread4~. Other array readers are available (such
as the IEM16 library). Sending a float into the inlet re-triggers the
ramp from the value given by the float.;
#X msg 138 93 60;
#X text 105 463 In 32bit Pure Data \, there is a limit of 4 million
samples (about 90 seconds) that Pd can address in a smooth fashion.
;
#X connect 11 0 15 0;
#X connect 13 0 11 0;
#X connect 14 0 11 0;
#X connect 15 0 16 0;
#X connect 21 0 11 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list