Re: [PD] latest version fro Power PC?

2020-09-25 Thread Miller Puckette via Pd-list
Nope.. the machine broke... I can't build for PPC anymore. (But I doubt it will make much difference now). cheers M On Fri, Sep 25, 2020 at 08:57:33PM -0300, Alexandre Torres Porres wrote: > I see we have 0.51-0 for old PPC Macintoshes but not 0.51-2 in > http://msp.ucsd.edu/software.html -

[PD] latest version fro Power PC?

2020-09-25 Thread Alexandre Torres Porres
I see we have 0.51-0 for old PPC Macintoshes but not 0.51-2 in http://msp.ucsd.edu/software.html - well, I'm assuming Miller forgot to upload 0.51-2, right? cheers ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->

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

2020-09-25 Thread IOhannes m zmölnig
On 2020-09-25 19:33, Miller Puckette via Pd-list wrote: > but for now the only way to do that is launch two processes (which you can > connect with netsend/netreceive). but you cannot launch a 2nd Pd from within running instance (at least not with vanilla means), whereas [pd~] does allow

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

2020-09-25 Thread Christof Ressi
btw, would it be thinkable to add the possibility to run the pd~ subprocess asynchronously? This would be definitely possible. I think you only need to set the pipe read end in the parent process to non-blocking. The parent process tries to read the subprocess output and sends a block of

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

2020-09-25 Thread Miller Puckette via Pd-list
For now pd~ is synchronous regardless of whether there are input/output audio signals or not. I've been thinking about making an async possibility, but for now the only way to do that is launch two processes (which you can connect with netsend/netreceive). There is a realtime object by which a

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

2020-09-25 Thread Antoine Rousseau
btw, would it be thinkable to add the possibility to run the pd~ subprocess asynchronously? Think of a subprocess running a large Gem patch, that would potentially produce large CPU spikes; you don't really care if this subprocess sometimes gets late, while you absolutely need the calling process

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

2020-09-25 Thread Roman Haefeli
On Fri, 2020-09-25 at 13:41 +0200, Roman Haefeli wrote: > On Fri, 2020-09-25 at 12:18 +0200, IOhannes m zmölnig wrote: > > doing quick benchmarks gives the following results: > > > > > implemtation | time (length=10) | > > > --|--| > > > 1

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

2020-09-25 Thread Roman Haefeli
On Fri, 2020-09-25 at 12:18 +0200, IOhannes m zmölnig wrote: > > doing quick benchmarks gives the following results: > > > implemtation | time (length=10) | > > --|--| > > 1 (repack/array) | 1.8ms| > > 2 (repack/tab) | 9.9ms

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

2020-09-25 Thread Christof Ressi
The "delay" setting is in ms, but the "-fifo" argument is in blocks. Note that the "delay" setting is only valid for the parent process. In the subprocess, all audio settings from the menu are ignored because the relevant settings are passed via the [pd~] object). Christof On 25.09.2020

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

2020-09-25 Thread IOhannes m zmölnig
On 2020-09-25 00:30, Benjamin ~ b01 wrote: > 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

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

2020-09-25 Thread Roman Haefeli
On Fri, 2020-09-25 at 00:30 +0200, Benjamin ~ b01 wrote > [...] I'm using a list-drip [...] This abstraction is from an pre-[list store]-era. Mathieu Bouchard went to great lengths to optimize what was possible at the time, but there was still no other way than to pass at least half of the list

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

2020-09-25 Thread Roman Haefeli
On Fri, 2020-09-25 at 00:30 +0200, Benjamin ~ b01 wrote: > > 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

[PD] [PD-announce] Click Tracker - Version 2 is out - MaxMSP integration

2020-09-25 Thread João Pais CT
Dear List, Version 2 of the Click Tracker is out. The main feature for this version is in the integration into *Max/MSP* (Cycling '74). You can now run the software in any of the following ways: - as an android app (https://bit.ly/click-tracker-mob or

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

2020-09-25 Thread cyrille henry
hello, if you don't mind using eternals, you can put all data in a table, then use tab_downsample from nusmuk_utils to create 2 tables with MSB and LSB, then the iem_tab library will provide the other mathematical object to multiply 1st table by 256 and add the other one. It should perform

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

2020-09-25 Thread Alexandre Torres Porres
Em sex., 25 de set. de 2020 às 03:47, Peter P. escreveu: > You might also want to check the list archives > > https://lists.puredata.info/search?P=b16.long-varispeed=Pd-list=20=-1 Cool, but which thread exactly? I'm an active reader and if you're referring to a thread you started yourself

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

2020-09-25 Thread Peter P.
* Alexandre Torres Porres [2020-09-25 08:38]: > > 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 > > Ok, Matt Barber explained to me how has this doesn't really work and I was > just

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

2020-09-25 Thread Alexandre Torres Porres
> 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 Ok, Matt Barber explained to me how has this doesn't really work and I was just fooled... I couldn't hear it with a sine tone but some of the