Pd-list July 2019

pd-list@lists.iem.at

37 participants
40 discussions

current GEM status?
by Alexandre Torres Porres 24 Jul '19

24 Jul '19

Hi, I was never a GEM user, but I'm curious. What's the current status of GEM? I know it had suffered issues with macOS for ages. I remember a "christmas GEM" offer with a "pre build" that attempted to resolve all that. Now I see on deken that a 0.94 is available, maybe I missed the big announcement. Anyway, I tried it and pix_video didn't work right for me on mojave. So I wonder what's the status of it, is it supposed to have dealt with all mac issues, what's still on the table to deal with? thanks

2 1

fish eye camera distortion correction
by Csaba Láng 23 Jul '19

23 Jul '19

Hi list, is there an easy way to correct fish eye camera image distortion? I think if a vortex kind of tool. Best, Popesz

5 8

10 years of PdCon09 today, a nostalgic
by Alexandre Torres Porres 19 Jul '19

19 Jul '19

Hi, exactly 10 years ago today, the 3rd International Pd Convention took place. Looking back 10 years in the past, it feels we were 100 years into the future :) I'm sharing some photos on my google drive https://drive.google.com/open?id=1vKk31r-wXdHbOpTuaHI121Akj4FY4cH9 And there's also a facebook album I uploaded today https://www.facebook.com/alexandre.porres/media_set?set=a.10157471164626683… maybe a few more pictures will come up from those who have it but never shared but now feel like sending me them 🙂 cheers

1 1

Re: [PD] OSC data from [list trim]
by Mitchell Turner 16 Jul '19

16 Jul '19

Christof, The first element of the list being a symbol is the exact problem and your split > float > append makes a functioning work around. Here is what I ended up with. [listen 8000( | | [netrecieve -u -b] | | [oscparse] | | [list trim] | | [list split 1] | | | | [f] | | | | | [list append] | | [route 1] I guess I’m not clear on why the first element after [list trim] is a symbol? Thanks so much for the help, Mitch > On Jul 13, 2019, at 1:33 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 3 > Date: Sat, 13 Jul 2019 18:46:23 +0200 > From: "Christof Ressi" <christof.ressi(a)gmx.at <mailto:christof.ressi@gmx.at>> > To: "Roman Haefeli" <reduzent(a)gmail.com <mailto:reduzent@gmail.com>>, Pd-List > <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>, "Miller Puckette" <msp(a)ucsd.edu <mailto:msp@ucsd.edu>> > Subject: Re: [PD] OSC data from [list trim] > Message-ID: > <trinity-c77aaaa8-5963-4469-9cc2-798d3807b5a5-1563036383216@3c-app-gmx-bs75> > > Content-Type: text/plain; charset=UTF-8 > > I think the problem lies somewhere else. There is a fundamental issue with [oscparse]: it breaks the address pattern into its parts and forms a Pd list, but treats numbers as symbols. > > In Mitchell's case, he might be sending an OSC message like "/1/toggle1 1", so [oscparse] outputs a list "1 toggle1 1". However, the first atom "1" in the list will be a symbol, so you can't route it with [route 1]. There's a workaround: split the list with [list split 1], pass the first atom through [f] (since Pd 0.48 it interprets symbols as floats) and join the two lists again with [list append]. > > @Miller: addresses like "/foo/1/bar/2" are very common and the output of [oscparse] can cause confusion. Would you agree that the number parts should be rather interpreted as floats? Would it be too late to change this? If we keep the current behavior, we should at least clearly document it (and show the workaround). > > [unpackOSC] doesn't have this problem because the address parts are cleary symbols and you can route them with [routeOSC /1 /2 /3 /4], etc. > > Christof > > >> Gesendet: Samstag, 13. Juli 2019 um 18:28 Uhr >> Von: "Roman Haefeli" <reduzent(a)gmail.com <mailto:reduzent@gmail.com>> >> An: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> >> Betreff: Re: [PD] OSC data from [list trim] >> >> On Sat, 2019-07-13 at 12:01 -0400, Mitchell Turner wrote: >>> >>> If I send this message “1 toggle1 1” to a [route 1], I expect the >>> message toggle1 1 to come out of the first outlet of route, however, >>> nothing comes out of the first outlet. >> >> >> There is a distinction in both worlds, Pd messages and OSC messages, >> between a two-element-list with float 1 and the symbols "toggle" on one >> hand and on the other a symbol containing "1 toggle". [route 1] catches >> only the former, while the latter is passed to the right outlet. >> >> Make sure that you send OSC messages with two atoms, '1' and 'toggle' >> instead of one symbolic atom '1 toggle'. >> >> Roman >> _______________________________________________ >> Pd-list(a)lists.iem.at <mailto: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>

3 2

ERROR writing "sock56"
by Maurin Donneaud 15 Jul '19

15 Jul '19

I can't open a patch made last year. Pd crash when opening the patch. pdsend errorname: >>error writing "sock56321513ee00": broken pipe<< Do someone have an idea about this? It is first time it happened to me Best, Maurin -- /* Maurin Donneaud - Creative technologist Industrial designer and programmer +33 627 321 616 35 Rue des Meuniers, 75012 Paris www.etextile.org */

2 1

slightly OT- PD weirdness under Windows -32 and 64 bit - is Linux better?
by Scott R. Looney 15 Jul '19

15 Jul '19

hey folks my PD on Windows saga continues. over the last day i've experienced: 15 second MIDI input delay on MIDI port input (32 and 64 bit vanilla) - Purr Data and the CEAMMC PD distribution had no issues. but for me using a Roland UM-ONE very basic USB- MIDI interface, PD was effectively not responding in even close to a timely manner. alll on PD 49.0 UI glitches in the CEAMMC matrix.ui object. the window containing it cannot be closed or minimized without resulting in a glitch making it blank and non-interactable. this is in both vanilla and CEAMMC distributions in 32 and 64 bit. Alexander Porres' mtx.ctl object worked great in PD vanilla but with the MIDI data delay i had, it was useless. switching to CEAMMC's PD build resulted in much better MIDI input latency but ruined the layout of the ELSE library's mtx.ctl object - back to the drawing board... on top of that there's a subpatcher that cannot be opened at all. it's very simple with numbers and [pack] objects. Windows shows that the window exists but i cannot view it. this error occurs on every version of PD i've tried on Windows, but works fine on the Mac. no other subpatchers are affected however, as far as i can tell. oh and switching to the ASIO driver produces horribly distorted audio, although MMIO seems to work fine. the sound card is an Apogee Duet, as the internal audio is pretty unusable. so, i'm disappointed enough in the inconsistency of performance under Windows(Win 10 64 bit Home on a ASUS ROG laptop with 16GB RAM) for what seems like a basic setup that i'm wondering about giving Linux a chance. this platform does VR audio and video fairly well but it seems like running PD is more of an experimental afterthought than a robust performance platform. so i'm considering a switch to Linux and obviously it would have to have good audio and MIDI performance, but i'd really like it to be easy to install and configure with minimal console and shell scripting. any recommends on some specific distributions? i had considered Hackintoshing it and will have to replace the Wifi card with a more compatible one but if there's an easy method to put a good performing Linux so i could dual boot, i'd be very interested. of course with an Apogee Duet, i'll probably run into the fact that the device isn't fully supported, as it seems to be. no easy answers it seems...

2 1

best non linear envelope design?
by Alexandre Torres Porres 15 Jul '19

15 Jul '19

Hi, I just implemented curved envelopes into my [else/envgen~] object. The exponential parameter is plainly getting a vertical distance, normalize it from 0 to 1 and apply a power raised exponential. For instance, a parameter of 4 is like using [pow~ 4] with an input from 0 to 1! I wonder if this is all that there is to generating exponential curves or if I should also look into other functions. Moreover, I also have a much simpler object called [else/adsr~] and I'm thinking of providing a hard coded exponential setting for it. What would be a good one and only choice for that? I mean a more "classic" and common design for the attack/decay and release stages. cheers

6 11

Re: [PD] Question about transmission order to serial port [comport] with two independent streams
by Christof Ressi 15 Jul '19

15 Jul '19

> The SLIP protocol has actually more overhead than what I'm thinking of. generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219. > On top of it it is more prone to generate errors with MIDI since it uses Bytes if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol). > Can a message going to comport be interrupted by another message that is being > sent to [comport] almost at the same time or will one message or packed list > always be processed completely before anything else will be sent to the same > [comport] object. message passing in Pd is synchronous, so there's no way two messages can interleave. still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply. Christof > Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr > Von: "Ingo Scherzinger" <eeemail(a)dynasample.com> > An: "'Christof Ressi'" <christof.ressi(a)gmx.at>, 'Pd-List' <pd-list(a)lists.iem.at> > Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams > > Thanks, Christof! > > The SLIP protocol has actually more overhead than what I'm thinking of. > On top of it it is more prone to generate errors with MIDI since it uses Bytes > that are also used as MIDI Status Bytes. > > My question is actually very simple: > > Can a message going to comport be interrupted by another message that is being > sent to [comport] almost at the same time or will one message or packed list > always be processed completely before anything else will be sent to the same > [comport] object. > > Ingo > > > > -----Original Message----- > > From: Christof Ressi [mailto:christof.ressi@gmx.at] > > Sent: Sunday, July 14, 2019 3:32 PM > > To: Ingo; Pd-List > > Subject: Aw: [PD] Question about transmission order to serial port [comport] > > with two independent streams > > > > When sending data over a serial connection, it's good to have some sort of > > protocol to distinguish messages. A very common protocol is SLIP > > https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol > > It's often used for streaming OSC messages (e.g. TCP or serial). You can > > encode in Pd with [mrpeach/slipenc] and decode on the Arduino with > > https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h > > > > On the other hand, MIDI is already a protocol (messages are delimited by > > status bytes) and you could send your display data on an unused MIDI > > channel or even as Sysex messages. > > > > Christof > > > > > Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr > > > Von: "Ingo" <ingo(a)miamiwave.com> > > > An: 'pd-list' <pd-list(a)iem.at> > > > Betreff: [PD] Question about transmission order to serial port > > > [comport] with two independent streams > > > > > > Hi there, > > > > > > I need to send both display data and MIDI out data to the same serial > > > port via USB using [comport] going to an Arduino Micro. > > > The MIDI goes on to the serial transmit pin and the display goes to > > > the I2C pins. > > > Unfortunately neither the display nor the MIDI data is very > > > predictable concerning timing. > > > > > > The display uses drip to send one character after the other and MIDI > > > is sending out manipulated data from the MIDI input whenever MIDI > > comes in. > > > Both senders are on different sections of the software and are not > > > synchronized in any way. > > > > > > Since I need to find a way to split up each stream inside of the > > > Arduino without meshing them up and causing errors my question is: > > > > > > Does Pd send one message (or packed numbers) with two or more values > > > without interruption? > > > If yes I could simply prepend an unused number (like e.g. 253 or 254) > > > as a header in front of each MIDI Byte. > > > If needed another one for the display data. > > > (The latter is probably not necessary since I can reset after each > > > MIDI Byte inside of the Arduino to keep sending again to the display.) > > > > > > Meshing up MIDI and display data would be absolutely chaotic! > > > If I can't guarantee that each Byte goes to the correct destination I > > > will have to use two separate arduinos. > > > > > > Thanks! > > > Ingo > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pd-list(a)lists.iem.at mailing list > > > UNSUBSCRIBE and account-management -> > > > https://lists.puredata.info/listinfo/pd-list > > > > > >

3 6

Question about transmission order to serial port [comport] with two independent streams
by Ingo 14 Jul '19

14 Jul '19

Hi there, I need to send both display data and MIDI out data to the same serial port via USB using [comport] going to an Arduino Micro. The MIDI goes on to the serial transmit pin and the display goes to the I2C pins. Unfortunately neither the display nor the MIDI data is very predictable concerning timing. The display uses drip to send one character after the other and MIDI is sending out manipulated data from the MIDI input whenever MIDI comes in. Both senders are on different sections of the software and are not synchronized in any way. Since I need to find a way to split up each stream inside of the Arduino without meshing them up and causing errors my question is: Does Pd send one message (or packed numbers) with two or more values without interruption? If yes I could simply prepend an unused number (like e.g. 253 or 254) as a header in front of each MIDI Byte. If needed another one for the display data. (The latter is probably not necessary since I can reset after each MIDI Byte inside of the Arduino to keep sending again to the display.) Meshing up MIDI and display data would be absolutely chaotic! If I can't guarantee that each Byte goes to the correct destination I will have to use two separate arduinos. Thanks! Ingo

2 2

Re: [PD] OSC data from [list trim]
by Mitchell Turner 13 Jul '19

13 Jul '19

Ok, I see. Thanks. — Mitch > On Jul 13, 2019, at 4:09 PM, pd-list-request(a)lists.iem.at wrote: > > Message: 2 > Date: Sat, 13 Jul 2019 21:55:58 +0200 > From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] OSC data from [list trim] > Message-ID: <21EC0C95-2330-4727-9CCB-E3941B112B12(a)iem.at <mailto:21EC0C95-2330-4727-9CCB-E3941B112B12@iem.at>> > Content-Type: text/plain; charset=utf-8 > > Am 13. Juli 2019 20:48:27 MESZ schrieb Mitchell Turner <mmturner2468(a)gmail.com <mailto:mmturner2468@gmail.com>>: > >> I guess I’m not clear on why the first element after [list trim] is a >> symbol? >> > > > because [oscparse] splits the osc-path into symbols-only. > > > mfg.fdz.gsf > IOhannes > > > -- > sent from my pdp-12

1 0

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 July 2019