[PD] b16.long-varispeed working? bypass the "onset" solution?

[Alexandre Torres Porres]

Howdy;

First, I'm not sure what I'm supposed to hear in the example
b16.long-varispeed or if it ain't working - I don't really get the example
either so I can't say.

Now, it seems the limit to tabread4~ is indexes up to 2ˆ24 and no Pd
vanilla patch can count over that, right? I tried [fexpr~ $x + $y] with an
input/increment of 1 and it stops at 2ˆ24 for instance. I also couldn't do
it with +~ and a feedback delay  with block size of 1.

But.. I have [else/ramp~] and it has an internal "sum" variable
which is a 'double', and I see it works just great to generate indexes over
that limit and [tabread4~] gets those values alright! I'm on macOS using
0.51-2, downloaded from miller's website (that is a 64bit binary, not the
32 one, but not Pd compiled with float = 64 bits, got it?).

Anyway, so, should I be aware that else/ramp~ may not work in some cases
(maybe the 32 bit mac binary provided by miller)? Why can't we have [expr~]
with a 'double' variable that can count over the 2ˆ24 limit and not worry
about (or "bypass") the "onset hack" of example b16?

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

Re: [PD] pd~ fifo flag and block delays

[Fede Camara Halac]


Aha! Thanks for clarifying! One more question, while I'm at it. Is the "delay" 
setting in blocks like the -fifo argument? 

Thanks a lot!

f


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

Re: [PD] pd~ fifo flag and block delays

[Christof Ressi]

The "delay" setting controls the ringbuffer size of the parent process 
(only true if not in "callback" mode). The "-fifo" argument for [pd~] 
controls the ringbuffer size of the subprocess.


Any CPU spikes which the subprocess ringbuffer can't handle will "spill" 
over to the parent process.


Christof

On 25.09.2020 04:14, Fede Camara Halac wrote:

Hi Christof,

Thanks! I am a bit confused, though. Is the "buffer (=delay)" the -fifo or are 
you talking about block sizes in parent and subprocess?

Best,

ffd


___
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] pd~ fifo flag and block delays

[Fede Camara Halac]

Hi Christof,

Thanks! I am a bit confused, though. Is the "buffer (=delay)" the -fifo or are 
you talking about block sizes in parent and subprocess?

Best,

ffd


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

Re: [PD] pd~ fifo flag and block delays

[Christof Ressi]

I think that having a small buffer for the subprocess is not a problem, 
as long as the buffer (= delay) of the parent process is large enough to 
absorb the CPU spikes of the subprocess.


If you use a single buffer for the subprocess, then the parent process 
practically has to absorb all CPU spikes.


Of course, it depends on the actual patch. For example, if the 
subprocess has several large FFTs (which are notorious for producing CPU 
spikes), it makes sense to use a higher buffer size to prevent it from 
blocking the parent process. If the subprocess has a fairly regular CPU 
load, you can get away with the minimal buffer size, even if the parent 
process has a rather small buffer size.


Christof

On 25.09.2020 00:41, ffdd cchh wrote:

Thanks, Miller.

Yes, it seems that is the case. I attach an example that shows the 
delayed block(s).


What do you mean inefficient? I do not see a drastic change in cpu 
usage on the very basic adc-to-dac example subprocess I include here.


As a side note, I noticed that loading -fifo 0 seems to crash pd !

Best,

ffdd


On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette > wrote:


That _should_ be correct.

fifos less than 2 are probably inefficient (but I dn't know that for
sure).

cheers
Miller

On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
> ???Hi,
>
> When using pd~ with -fifo 1, do you get a delay of 1 block like
in throw/catch scenario?
>
> Thanks!
>
> fd
>
> fdch.github.io 
>
>
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->

https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Uyv-HqXmCoj0l9209QG7_r5nfJVd8i8hyj0jSDRm6FzZv6t-9DKLtwT6Zaba$




--
fdch.github.io 

___
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

[PD] fast way to convert two 8 bit data to one 16 bit data in big lists ?

[Benjamin ~ b01]

hi,

I'm looking for a fast way to convert two 8 bit data to one 16 bit data
in big lists
a device send continuously packets of 16 000 bytes threw the network to
udpreceive
at the moment, to reconstitute from two bytes a 16 bit value, I'm using
a list-drip and a counter to discriminate the MSB and LSB and do the
*256 and + operation
the aim is to feed a table with the result (see attached) and produce
sound from it
it works with packets of 2 000 bytes but pd freeze with bigger packets
I'm wondering if there is a better way to achieve this ?

thk
b
#N canvas 6 56 970 798 10;
#X obj 182 117 list-drip;
#X obj 156 344 t f b;
#X obj 237 374 f;
#X obj 267 374 + 1;
#X obj 222 170 f;
#X obj 252 170 + 1;
#X obj 234 151 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 282 171 % 2;
#X obj 155 236 spigot;
#X obj 202 238 spigot;
#X obj 183 143 t f f b;
#X obj 222 192 t f f;
#X obj 249 215 invert;
#X obj 202 259 * 256;
#X obj 155 279 +;
#X msg 182 80 0 255 0 255 255 0 255 0 255 12 55 48 255 255 255 0 5
1 255 214;
#X obj 294 375 % 20;
#N canvas 0 50 450 250 (subpatch) 0;
#X array data 100 float 3;
#A 0 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2 35357.2
35357.2 35357.2;
#X coords 0 0 100 66000 200 140 1 0 0;
#X restore 363 280 graph;
#X obj 156 402 tabwrite data;
#X connect 0 0 10 0;
#X connect 1 0 18 0;
#X connect 1 1 2 0;
#X connect 2 0 3 0;
#X connect 2 0 18 1;
#X connect 3 0 16 0;
#X connect 4 0 5 0;
#X connect 4 0 11 0;
#X connect 5 0 7 0;
#X connect 6 0 4 0;
#X connect 7 0 4 1;
#X connect 8 0 14 0;
#X connect 9 0 13 0;
#X connect 10 0 8 0;
#X connect 10 1 9 0;
#X connect 10 2 4 0;
#X connect 11 0 8 1;
#X connect 11 1 12 0;
#X connect 12 0 9 1;
#X connect 13 0 14 1;
#X connect 14 0 1 0;
#X connect 15 0 0 0;
#X connect 16 0 2 1;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pd~ fifo flag and block delays

[ffdd cchh]

Thanks, Miller.

Yes, it seems that is the case. I attach an example that shows the delayed
block(s).

What do you mean inefficient? I do not see a drastic change in cpu usage on
the very basic adc-to-dac example subprocess I include here.

As a side note, I noticed that loading -fifo 0 seems to crash pd !

Best,

ffdd


On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette  wrote:

> That _should_ be correct.
>
> fifos less than 2 are probably inefficient (but I dn't know that for
> sure).
>
> cheers
> Miller
>
> On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
> > ???Hi,
> >
> > When using pd~ with -fifo 1, do you get a delay of 1 block like in
> throw/catch scenario?
> >
> > Thanks!
> >
> > fd
> >
> > fdch.github.io
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Uyv-HqXmCoj0l9209QG7_r5nfJVd8i8hyj0jSDRm6FzZv6t-9DKLtwT6Zaba$
>


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

[PD] pd~ fifo flag and block delays

[Fede Camara Halac]

Hi,

When using pd~ with -fifo 1, do you get a delay of 1 block like in throw/catch 
scenario? 

Thanks!

fd

fdch.github.io


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

Re: [PD] pd~ fifo flag and block delays

[Miller Puckette via Pd-list]

That _should_ be correct.

fifos less than 2 are probably inefficient (but I dn't know that for
sure).

cheers
Miller

On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
> ???Hi,
> 
> When using pd~ with -fifo 1, do you get a delay of 1 block like in 
> throw/catch scenario? 
> 
> Thanks!
> 
> fd
> 
> fdch.github.io
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Uyv-HqXmCoj0l9209QG7_r5nfJVd8i8hyj0jSDRm6FzZv6t-9DKLtwT6Zaba$
>  



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

[PD] pd~ fifo flag and block delays

[Fede Camara Halac]

Hi,

When using pd~ with -fifo 1, do you get a delay of 1 block like in throw/catch 
scenario? 

Thanks!

fd

fdch.github.io


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

Re: [PD] [pii2c] keeps and resends previous messages when addresses change

[Martin Peach]

I uploaded a new version of [pii2c] yesterday via deken. It has some
slight changes, (mainly adding optional address to the read message).
I still don't get the double sends. I attach my code for teensy that
listens on all the addresses. When I try your patch with it, the
teensy only receives on the intended address. If I do 'i2cdetect -y 1'
in the terminal it receives on all addresses 0x03-0x77.

Martin


On Wed, Sep 23, 2020 at 11:49 AM Martin Peach  wrote:
>
> Before I test this, I notice you use Wire for the i2c slaves. Wire is
> known to not work properly in slave mode.
> I use this library for teensy i2c, it works very well:
> https://github.com/nox771/i2c_t3
> But I'll try your code later and see what I get.
>
> Martin
>
> On Wed, Sep 23, 2020 at 3:40 AM Alexandros  wrote:
> >
> > Sorry for coming back to this thread after so long, didn't have a Pi at
> > hand. I have attached a very simple patch which reproduces the bug.
> > You'll need to connect two I2C slave Teensy LC to the Pi. I have also
> > attached the two Arduino files that should be loaded to the Teensies.
> >
> > What happens with this setup is that the Teensy that listens to 0x09
> > (i2c_mess2.ino file) receives messages even when something is sent to
> > 0x0A. The Teensy that listens to 0x0A (i2c_mess1.ino file) doesn't seem
> > to be receiving anything.
> >
> > One Teensy prints to the serial console and the other responds by
> > lighting up and turning off the LED on pin 13.
> >
> > On 12/9/20 11:02 μ.μ., Martin Peach wrote:
> > > On Thu, Sep 10, 2020 at 2:25 PM Alexandros  wrote:
> > >> When trying to send messages to two I2C slaves from the Pi with [pii2c]
> > >> the following happens:
> > >>
> > >> If I send this message to [pii2c 0x0A]:
> > >> "write 3 127 7"
> > >>
> > >> it arrives properly at the slave address 0x0A.
> > >>
> > >> If I change the address to 0x09 with the message "addr 0x09" and then
> > >> send this message:
> > >> "write 97"
> > >>
> > >> then both messages will be sent to the respective slaves, meaning that
> > >> "3 127 7" will be sent to slave 0x0A and "97" to slave 0x09. If I then
> > >> change the message sent to 0x09 to "98", this will be sent to 0x09, but
> > >> again "3 127 7" will be sent to 0x0A. If I resend "3 127 7" to 0x0A,
> > >> "98" (the last message set to 0x09) will be sent to 0x09 as well.
> > >>
> > >> The same behavior occurs when I send the message "write 0x09 98". The
> > >> same behavior also occurs if I use two different [pii2c] objects, like 
> > >> this:
> > >>
> > >> [write 3 127 7(
> > >> |
> > >> [pii2c 0x0A]
> > >>
> > >> [write 97(
> > >> |
> > >> [pii2c 0x09]
> > >>
> > >>
> > > Hmmm I don't get this. Do you have a patch that will reproduce the bug?
> > > (I am also able to send messages longer than 32 bytes, with
> > > MAX_I2C_BUF_SIZE 64 in my copy of pii2c.c.)
> > > I used a teeny 3.2 as a slave (using i2c_t3 from
> > > https://github.com/nox771/i2c_t3) listening on all addresses. It only
> > > receives the messages on the addresses I set in the Pd patch.
> > >
> > > Perhaps you have a hidden [pii2c 0x0A] somewhere that is also
> > > receiving your write messages.
> > > Since [pii2c] is using the same memory space for each message any new
> > > message will effectively erase the old ones, so it's hard to explain
> > > two different messages coming from a single object.
> > >
> > > Martin


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

Re: [PD] question regarding symboltable

[hans w. koch]

thanks for confirming, johannes!

for now i settled for breaking up the numbers in chunks of 6 digits without 
using makefilename.
but i agree:
> on the long run, we should just improve the way numbers are written to disk.

best

hans


> Am 24.09.2020 um 13:53 schrieb IOhannes m zmoelnig :
> 
> On 2020-09-24 10:40, hans w. koch wrote:
>> has this changed somehow since or should it still be avoided?
> 
> nothing changed.
> 
>> or is there a way to “flush” the symboltable at runtime?
> 
> no.
> 
> [makefilename] is definitely the wrong tool to solve the problem
> (although it's probably the one that is available right now, in Pd-vanilla).
> 
> on the long run, we should just improve the way numbers are written to disk.
> 
> gfadsrm
> IOhannes
> 
> 
> ___
> 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] question regarding symboltable

[IOhannes m zmoelnig]

On 2020-09-24 10:40, hans w. koch wrote:
> has this changed somehow since or should it still be avoided?

nothing changed.

> or is there a way to “flush” the symboltable at runtime?

no.

[makefilename] is definitely the wrong tool to solve the problem
(although it's probably the one that is available right now, in Pd-vanilla).

on the long run, we should just improve the way numbers are written to disk.

gfadsrm
IOhannes


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

[PD] question regarding symboltable

[hans w. koch]

i seem to recall, that using [makefilename] a lot (i.e. in the range of 1e+08) 
will flood the symboltable and at best slow down pd, at worst crash it.
on the pd list i found a thread about that from 2002 with miller saying:
In general, it's a bad idea in Pd to write externs which create indeterminate 
numbers of symbols at run time. 
https://lists.puredata.info/pipermail/pd-list/2002-09/007966.html

has this changed somehow since or should it still be avoided?
or is there a way to “flush” the symboltable at runtime?

i am asking in the context of pd double, exploring strategies for storing big 
numbers. 
so far the most reliable one involves [makefilename %.0f] and fromsymbol as 
discussed in this thread recently 
(https://lists.puredata.info/pipermail/pd-list/2020-09/128113.html).
but if that creates a problem with symboltable, i´d try other options (e.g. 
splitting them up into parts).

thanks for confirming or appeasing my fears

hans





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