Pd-list June 2020

pd-list@lists.iem.at

50 participants
82 discussions

[PD-announce] AoO (audio over OSC) v2.0-pre2
by Christof Ressi 29 Jun '20

29 Jun '20

Dear list, here's a new pre-release for the AoO multichannel audio streaming library. In the last two months, the library has been seen many improvements and has been used successfully in our Virtual Rehearsal Room project (see vrr.iem.at <https://vrr.iem.at/>). Binaries for all common platforms (Windows, macOS, Linux, ARM boards) are available on Deken (search for "aoo"). The source code can be found here: https://git.iem.at/cm/aoo See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd, aoo_server.pd) for usage instructions. If you want to stream between different home networks (without port forwarding), you can use [aoo_client] and connect to our public AoO server at the IEM (hostname: vrr.iem.at, port: 7077). You can easily set up your own AoO server by running a Pd patch containing [aoo_server <port>] on your web server. --- Selected features: # create audio networks of any topology with arbitrary ad-hoc connections # [aoo_send~] / [aoo_receive~] take a port number and ID, so multiple objects (within a single Pd instance) can operate on the same port. Additionally, you can have multiple objects across different Pd instances (using different port numbers). # [aoo_send~] can stream to several destinations simultaneously; # [aoo_receive~] can receive several AoO streams simultaneously, summing the signals # AoO is connectionless: streams can start/stop at any time, enabling a "message-based audio" approach. # AoO sinks can "invite" sources, i.e. ask them to send audio. The source may follow the invitation or decline it. # AoO sinks and sources can operate at different blocksizes and samplerates # the streaming format can be set independently for each source; currently only PCM (uncompressed) and Opus (compressed) are implemented, but this can be easily extended with the AoO codec plugin API. # audio encoding/decoding is multithreaded # adjustable resending mechanism for dropped packets # adjustable jitter buffer size. # [aoo_server] / [aoo_client] implement the UDP hole punching technique to establish peer2peer connections between different home networks. # AoO is actually a C++ library with a C interface, so it can be used in apps or embedded devices (like the ESP32). An implementation for Supercollider is already planned. --- For questions, bug reports or feature requests, please open an issue at https://git.iem.at/cm/aoo/-/issues. We're very happy about any kind of feedback! Christof _______________________________________________ Pd-announce mailing list Pd-announce(a)lists.iem.at https://lists.puredata.info/listinfo/pd-announce

3 4

Re: [PD] [PD-announce] AoO (audio over OSC) v2.0-pre2
by Christof Ressi 29 Jun '20

29 Jun '20

Hi, > and tried to install aoo via deken, but it does not show up that's weird. You should get aoo[v2.0-pre2](Darwin-amd64-32)(Linux-amd64-32)(Linux-arm64-32)(Linux-armv7-32)(Linux-i386-32)(Windows-amd64-32)(Windows-i386-32).dek "Linux-armv7-32" should run on the Raspberry Pi. Can you try searching for libraries like "else" or "cyclone" which have dedicated Armv7 versions and see if they show up? Christof PS: In the Deken settings you can disable "hide incompatible externals", so the result should definitely show up in the next search. On 29.06.2020 10:10, Frederic Robinson wrote: > Hi, > >> The vision of AoO is that a network of computers becomes a modular system >> > i love that vision! > >> an ensemble of cheap wireless I/O devices >> > I have a mobile modular system of Raspberry Pis running PD with local > speakers and sensors , and tried to install aoo via deken, but it does > not show up. I suppose aoo currently does not run on that > architecture? (sorry, my technical knowledge is limited..) > > best > f > > -- > Frederic Robinson > Scientia PhD Candidate || Spatial Sonic Interaction Design > @ UNSW Creative Robotics Lab & Interactive Media Lab > https://robinson.audio | +61 478 429 800‬ > On 24 Jun 2020, 19:49 +1000, Christof Ressi <info(a)christofressi.com>, > wrote: >> >> Hi, >> >> the first use case was an audio installation by Bill Fontana in Graz >> (March - June) where we placed environmental streaming devices at 8 >> different places in the city and streamed the sounds to other places. >> >> Then we used in April-June for the VRR project (https://vrr.iem.at/) >> where students of contemporary classical music, who couldn't leave >> their cities/countries because of the Covid restrictions, could >> rehearse in a virtual rehearsal room which we've implemented in Pd. >> Currently it's being used in computer music seminars where students >> play as an ensemble of interconnected instruments. >> >> The vision of AoO is that a network of computers becomes a modular >> system: every device can be connected to any other device on the fly. >> For example, I might want to send 5 seconds of sound to player A, >> then receive 4 seconds from player B, do something with and send the >> result to some (wireless) speakers, etc. >> >> Another idea is to have an ensemble of cheap wireless I/O devices >> (microphone + amplifier) running the AoO library (C++) as a portable >> multichannel system. >> >> Christof >> >> On 24.06.2020 09:04, Frederic Robinson wrote: >>> Hi Christof, >>> >>> That sounds very exciting! I’ll try this out as soon as I can. >>> >>>> In fact, that is one of the main use cases for this library ;-) >>> I’m curious, what kind of projects did you use this in? >>> >>> Best regards, >>> Frederic >>> >>> >>> -- >>> Frederic Robinson >>> Scientia PhD Candidate || Spatial Sonic Interaction Design >>> @ UNSW Creative Robotics Lab & Interactive Media Lab >>> https://robinson.audio | +61 478 429 800‬ >>> On 23 Jun 2020, 10:05 +1000, Christof Ressi >>> <info(a)christofressi.com>, wrote: >>>> >>>> Hi, >>>> >>>>> Do you have experience with sending from one source to multiple >>>>> devices via Wifi? >>>> Sure, we did this all the time. In fact, that is one of the main >>>> use cases for this library ;-) >>>> >>>> If you send within a private network, you can use the "pcm" format >>>> for uncompressed audio, but for the public internet you might >>>> consider using the "opus" format for substantially lower bandwidth, >>>> especially when you're sending to many endpoints. A stereo 16-bit >>>> PCM stream @ 44.1 kHz takes about 1.4 Mbit/s. With Opus you can set >>>> the bandwidth to 120000 (= 128 kBit/s) and still get decent >>>> quality. This means you can send 11 opus stream for a single PCM >>>> stream :-) >>>> >>>> Christof >>>> >>>> On 23.06.2020 01:28, Frederic Robinson wrote: >>>>> Dear Christof, >>>>> >>>>> I just learned about this library. Looks amazing, great work! >>>>> >>>>> Do you have experience with sending from one source to multiple >>>>> devices via Wifi? >>>>> >>>>> Best regards, >>>>> Frederic >>>>> >>>>> >>>>> -- >>>>> Frederic Robinson >>>>> Scientia PhD Candidate || Spatial Sonic Interaction Design >>>>> @ UNSW Creative Robotics Lab & Interactive Media Lab >>>>> https://robinson.audio | +61 478 429 800‬ >>>>> On 22 Jun 2020, 23:22 +1000, Christof Ressi >>>>> <info(a)christofressi.com>, wrote: >>>>>> >>>>>> Dear list, >>>>>> >>>>>> here's a new pre-release for the AoO multichannel audio streaming >>>>>> library. In the last two months, the library has been seen many >>>>>> improvements and has been used successfully in our Virtual >>>>>> Rehearsal Room project (see vrr.iem.at <https://vrr.iem.at/>). >>>>>> >>>>>> Binaries for all common platforms (Windows, macOS, Linux, ARM >>>>>> boards) are available on Deken (search for "aoo"). The source >>>>>> code can be found here: https://git.iem.at/cm/aoo >>>>>> >>>>>> See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd, >>>>>> aoo_server.pd) for usage instructions. >>>>>> >>>>>> If you want to stream between different home networks (without >>>>>> port forwarding), you can use [aoo_client] and connect to our >>>>>> public AoO server at the IEM (hostname: vrr.iem.at, port: 7077). >>>>>> You can easily set up your own AoO server by running a Pd patch >>>>>> containing [aoo_server <port>] on your web server. >>>>>> >>>>>> --- >>>>>> >>>>>> Selected features: >>>>>> >>>>>> * create audio networks of any topology with arbitrary ad-hoc >>>>>> connections >>>>>> * [aoo_send~] / [aoo_receive~] take a port number and ID, so >>>>>> multiple objects (within a single Pd instance) can operate on >>>>>> the same port. Additionally, you can have multiple objects >>>>>> across different Pd instances (using different port numbers). >>>>>> * [aoo_send~] can stream to several destinations simultaneously; >>>>>> * [aoo_receive~] can receive several AoO streams >>>>>> simultaneously, summing the signals >>>>>> * AoO is connectionless: streams can start/stop at any time, >>>>>> enabling a "message-based audio" approach. >>>>>> * AoO sinks can "invite" sources, i.e. ask them to send audio. >>>>>> The source may follow the invitation or decline it. >>>>>> * AoO sinks and sources can operate at different blocksizes and >>>>>> samplerates >>>>>> * the streaming format can be set independently for each >>>>>> source; currently only PCM (uncompressed) and Opus >>>>>> (compressed) are implemented, but this can be easily extended >>>>>> with the AoO codec plugin API. >>>>>> * audio encoding/decoding is multithreaded >>>>>> * adjustable resending mechanism for dropped packets >>>>>> * adjustable jitter buffer size. >>>>>> * [aoo_server] / [aoo_client] implement the UDP hole punching >>>>>> technique to establish peer2peer connections between >>>>>> different home networks. >>>>>> * AoO is actually a C++ library with a C interface, so it can >>>>>> be used in apps or embedded devices (like the ESP32). An >>>>>> implementation for Supercollider is already planned. >>>>>> >>>>>> --- >>>>>> >>>>>> For questions, bug reports or feature requests, please open >>>>>> an issue at https://git.iem.at/cm/aoo/-/issues. We're very >>>>>> happy about any kind of feedback! >>>>>> >>>>>> Christof >>>>>> >>>>>> _______________________________________________ >>>>>> Pd-announce mailing list >>>>>> Pd-announce(a)lists.iem.at >>>>>> https://lists.puredata.info/listinfo/pd-announce >>>>>>

1 0

Subject:,Re: exiting edit mode ...
by Jean-Yves Gratius 26 Jun '20

26 Jun '20

On my linux (lubuntu 18.04.4 LTS) this happens too, from pd 0.49.0 I also tested with 0.48.0, 0.48.1, 0.48.2 that don't have this behaviour. Jean-Yves Gratius On 26/06/2020 12:00, pd-list-request(a)lists.iem.at wrote: > Subject: > Re: [PD] exiting edit mode ... > From: > oliver <oliver(a)klingt.org> > Date: > 25/06/2020 à 13:21 > > To: > pd-list(a)mail.iem.at > > > On 2020-06-25 13:05, Dan Wilcox wrote: >> As with most things, that sounds like a bug. >> >> What's missing is the info on the platform you are using. As you write >> "CTRL+E" I assume it's Windows. >> > > > It's also on LINUX (Debian Buster with PD 0.51), i tested both platforms. > > (I use "CTRL" as a shorthand for Strg, Command, Apple etc. just to > make clear it's not "Shift" or "Alt") > > Unfortunately i haven't got a Mac at hand to test there, but i assume > it's the same there, and that's a regression from PD 0.48 > > > > Best > > Oliver

1 0

Re: [PD] exiting edit mode ...
by Dan Wilcox 25 Jun '20

25 Jun '20

As with most things, that sounds like a bug. What's missing is the info on the platform you are using. As you write "CTRL+E" I assume it's Windows. > On Jun 25, 2020, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Date: Wed, 24 Jun 2020 20:44:47 +0200 > From: oliver <oliver(a)klingt.org <mailto:oliver@klingt.org>> > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: [PD] exiting edit mode ... > Message-ID: <9cc522e0-586b-a5b1-ac15-d30531033ad1(a)klingt.org <mailto:9cc522e0-586b-a5b1-ac15-d30531033ad1@klingt.org>> > Content-Type: text/plain; charset=UTF-8; format=flowed > > hi, > > recently i had the feeling that i had to do CTRL+E more often than i > used to to get out of edit mode. > > on a version comparison, i found out that this is actually true. > > since PD 0.50 (or was this already introduced in 0.49 ?), when you enter > edit mode to f.e. type something into a message box, you have to exit > the edit mode twice: > > once to leave the message box, and once to exit edit mode. > > i compared this behaviour with PD 0.48, where hitting CTRL+E after > editing a message box did both things at once (which is much more fluid > and the behaviour that i would personally prefer). > > is this ("new") behaviour intended and > what is the reasoning behind this ? > > best > > oliver -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

2 1

exiting edit mode ...
by oliver 24 Jun '20

24 Jun '20

hi, recently i had the feeling that i had to do CTRL+E more often than i used to to get out of edit mode. on a version comparison, i found out that this is actually true. since PD 0.50 (or was this already introduced in 0.49 ?), when you enter edit mode to f.e. type something into a message box, you have to exit the edit mode twice: once to leave the message box, and once to exit edit mode. i compared this behaviour with PD 0.48, where hitting CTRL+E after editing a message box did both things at once (which is much more fluid and the behaviour that i would personally prefer). is this ("new") behaviour intended and what is the reasoning behind this ? best oliver -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\ ////////////////////////////////////////////////////////

1 0

Re: [PD] tcpserver, flush?
by Dan Wilcox 24 Jun '20

24 Jun '20

With the net updates for Pd 0.51, I would also add that multicast should also be working well. If you are working only with your own subnet, ie. something like a wireless router, you could use multicast UDP. > On Jun 24, 2020, at 12:00 PM, pd-list-request(a)lists.iem.at wrote: > > Finally, if you want messages to get out as fast as possible, then TCP > might be the wrong approach anyway and you might want to use UDP > instead. Of course, UDP is unreliable, but for things like continous > streams of data this is often not a problem. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

1 0

Re: [PD] tcpserver, flush?
by rolfm＠dds.nl 23 Jun '20

23 Jun '20

thanks for all the hints, i hope to test some more tomorrow . rolf Roman Haefeli schreef op 15-06-2020 17:24: > Hi Rold, > Hi Martin > > On Mon, 2020-06-15 at 09:44 -0400, Martin Peach wrote: >> Based on my assumptions, it may be that the OS is delaying sending >> the >> messages in case you're not finished sending them. You need a break >> of >> some minimum time before the whole lot gets sent. > > That probably forces the underlying framework to create messages of the > desired format. What if you want to send many messages immediately? > >> The OS may delay >> longer in the case of a wireless connection to avoid network >> congestion. This is because TCP has no concept of packet or >> 'datagram' >> like UDP -- you can keep sending until you close the connection, so >> one way is to close the connection after each message. Another way >> would be to use a longer metro tick period so the stack times out and >> sends. > > How can you know what is a time that works (over wifi, vpn, ethernet)? > That is not using the TCP protocol as intended. > >> Also try sending a longer message to force it to be sent. > > What a horrible advice! Just stuff more unnecessary data into to pipe > to force it to put delimiters at the right spot! > > Seriously, what you lack is some kind of delimiting mechanism in order > to be able to transmit packets through a stream-oriented protocol such > as TCP or serial line. mrpeach tcp classes do a great job in > obfuscating the true nature of TCP by outputting randomly assembled > lists of floats instead of a stream of float (like iemnet). > > OTOH, mrpeach comes with [slipenc] and [slipdec] which implement SLIP > which is probably the simplest available delimiting mechanism. > > > This should work: > > [send <your message encoded as list of bytes>( > | > [slipenc] > | > [tcpclient] > > [tcpserver] > | > [slipdec] > | > [print] > > > I'm sure there is some implementation of SLIP for the NodeMCU > somewhere. > > Things would get more complicated when you receive TCP data from many > clients in parallel, but you seem to want to only send to many clients. > > An alternative approach would be to use UDP instead of TCP. UDP thinks > already in packets, but chances are that packets are lost on the way, > while TCP is absolutely reliable. > > Roman

2 2

Re: [PD] mrpeach under raspbian
by Ivan Petkov 23 Jun '20

23 Jun '20

Hello, I had the same problem on raspbian, unfortunately couldn’t find the reason why mrpeach doesn't work. However, I found out that I can use netreceive and netsend to establish OSC communication. I had to add osc/ to all OSC- objects, i.e. osc/unpackOSC, osc/pipelist etc. I hope, this helps Ivan > > 1. [pd] mrpeach under raspbian (Maik Hester) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 19 Jun 2020 14:48:21 +0200 > From: Maik Hester <maik.hester(a)gmx.de> > To: pd-list(a)iem.at > Subject: [PD] [pd] mrpeach under raspbian > Message-ID: <906189bc-7607-b653-81c3-c7935dfc91a5(a)gmx.de> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello list, > > does anyone know how to get mrpeach running under raspbian? > > Neither adding pd-mrpeach, setting the search path to /usr/lib/pd/extra, declaring [declare -path mrpeach] nor [declare > /usr/lib/pd/extra] lent to any success. > > Pd is still not able to create [slipdec] [unpackOSC] and [routeOSC], and the program crashes/closes/vanishes a couple of > seconds after opening the patch (which is working fine under ubuntu and OSX). > > What else can I do to get the patch running on the raspberry-pi? > > Thanks for any help, > Maik >

2 1

How to establish a data channel beside Audio Over Osc (was : [PD-announce] AoO (audio over OSC) v2.0-pre2)
by Jean-Yves Gratius 23 Jun '20

23 Jun '20

Great project ! many thanks. I have a side question : How could I communicate between two remote instances of Pd using AOO ? Beyond audio channels, I need a data channel in order to transmit control rate messages betwwen the two pd instances. Shoud I use netsend and netreceive on the same udp channel with a specific selector ? Jean-Yves Gratius On 23/06/2020 01:08, pd-list-request(a)lists.iem.at wrote: > Subject: > [PD] [PD-announce] AoO (audio over OSC) v2.0-pre2 > From: > Christof Ressi <info(a)christofressi.com> > Date: > 22/06/2020 à 15:20 > > To: > pd-announce(a)lists.iem.at > > > Dear list, > > here's a new pre-release for the AoO multichannel audio streaming > library. In the last two months, the library has been seen many > improvements and has been used successfully in our Virtual Rehearsal > Room project (see vrr.iem.at <https://vrr.iem.at/>). > > Binaries for all common platforms (Windows, macOS, Linux, ARM boards) > are available on Deken (search for "aoo"). The source code can be > found here: https://git.iem.at/cm/aoo > > See the help patches (aoo_send~-help.pd, aoo_receive~-help.pd, > aoo_server.pd) for usage instructions. > > If you want to stream between different home networks (without port > forwarding), you can use [aoo_client] and connect to our public AoO > server at the IEM (hostname: vrr.iem.at, port: 7077). You can easily > set up your own AoO server by running a Pd patch containing > [aoo_server <port>] on your web server. >

2 2

[expr] - fmod weirdness
by oliver 23 Jun '20

23 Jun '20

hi, i just stumbled upon a problem when i tried to use [expr fmod] to produce a modified [wrap] object that should be able to produce a float wrapped around an arbitrary limit (not just 1 as in vanilla's [wrap]) i know that there are many ways to do this but i tried the [expr] way and noticed something weird (not sure if that's a bug, though): i am getting "inconsistent" results from the [expr] object. whereas if i'm cranking out a "handmade" version, the results are what they are supposed to be. i attached the patch that shows the problem is this a single / double precision case ? best oliver -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ /////////////// http://pendler.klingt.org ////////////// \\\\\\\\\\\\\\\ http://oliver.klingt.org \\\\\\\\\\\\\\ ////////////////////////////////////////////////////////

2 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list June 2020