Pd-list December 2015

pd-list@lists.iem.at

56 participants
94 discussions

MobMuPlat - data from several iPads to one PC
by Christian Fischer 14 Jan '16

14 Jan '16

Hi there, not sure whether I can make out the forest for the trees after x hours of fiddling… What would be the best way to send data (one way) from several iPads to one master patch on PC, connected adhoc wireless? So far I tried only with one iPad, used MobMuPlat and simple ‚netsend' / ‚netreceive'. For one iPad it worked pretty fine! Now I wonder what about several iPads. Can’t test before Monday, but I would like to prepare everything before… The idea is several people use the iPads as interfaces to manipulate a master patch on a PC connected to interface, several speakers etc… They do not have to get any feedback from master patch. Data flows only one way. MobMuPlat does not take ‚packOSC‘. Would ‚LANdini‘ be better for several iPads (could not get it running so far. still trying…) Or is there something else? Any experiences? Thanx & Best! chris

4 8

Re: [PD] [pix_data] - convert rgb values to pd canvas format
by João Pais 12 Jan '16

12 Jan '16

Ok. Do you know what should be done to convert to Pd's rgb format? > I'm pretty sure the 4th value is alpha > > Sent from my iPhone > >> On Dec 31, 2015, at 7:53 AM, João Pais <jmmmpais(a)gmail.com> wrote: >> >> Hello list, >> >> I'm trying to use [pix_data] to get the RGB values from an image, and >> color a canvas using them. But the results come out a bit weird, as not >> all colors match. >> >> I can try to some a more detailed patch in a couple of days, but wanted >> to ask first the there is any example of how to use the values coming >> out of [pix_data]: >> - should the gray value be used? >> - the middle outlet should send a list of RGB values, but I noticed >> that instead a list of 4 values comes out. This isn't documented, what >> is the 4th value? >> >> Attached are 2 pictures that should exemplifiy the issue: >> - rgb.tif - a rgb palette >> - rgb-conv.tif - the result after my interpretation of the data >> >> Best, >> >> Joao >> <rgb.tif> >> <rgb-conv.tif> >> _______________________________________________ >> Pd-list(a)lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list

6 12

Array List View
by Jonathan Wilkes 02 Jan '16

02 Jan '16

Hi list,I'm done implementing the Windows menu in the GUI port. Now-- does anyone ever use the Array List View? Can't this just be a GOP abstraction? Especially since it doesn't allow keyboard-only entry... On the other hand, if you widen the window you get this fat motif scrollbar, which is fun... -Jonathan

5 19

Re: [PD] Apply button missing from properties in 0.46.7
by Dan Wilcox 01 Jan '16

01 Jan '16

“switch to linux” … real helpful :P I brought this up recently on pd-dev: http://lists.puredata.info/pipermail/pd-dev/2015-11/020478.html <http://lists.puredata.info/pipermail/pd-dev/2015-11/020478.html> The curent situation is a bit half-way as the button was removed to match the Apple Human Interface Guidelines (aka persistent changes are saved by default, hence no “Apply” button). The problem is that updates are not applied until *after* the dialog is closed. This means making small GOP changes, for instance, is a pain in the ass since you have to keep opening and closing the dialog. IMO this works *against* the HIG as is far worse than simply having a button. There are two solutions: 1. simply bring back the Apply button on OSX, I did this on my version of Vanilla by commenting out some if statements in the tcl code 2. add apply code in the tcl to update the canvas/gui object whenever changes are applied to any text box in the dialog I’ll look into option 2 as it’s really the best solution. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 3, 2015, at 10:11 AM, pd-list-request(a)lists.iem.at wrote: > > From: IOhannes m zmoelnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > Date: December 3, 2015 at 4:57:04 AM MST > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > Subject: Re: [PD] Apply button missing from properties in 0.46.7 > > > On 2015-12-03 12:41, Si Mills wrote: >> Hi >> >> Is the omission of the Apply btn in the properties dialogues (present in >> Pd-extended) a feature of latest vanilla build or a bug? > > a feature¹. > > http://lists.puredata.info/namazu/pd-list/namazu.cgi?query=apply+button <http://lists.puredata.info/namazu/pd-list/namazu.cgi?query=apply+button> > > gsdfmt > IOhannes > > ¹ that should go away. in the meantime you could switch to linux where > there *is* an apply button.

5 9

[pix_data] - convert rgb values to pd canvas format
by João Pais 31 Dec '15

31 Dec '15

Hello list, I'm trying to use [pix_data] to get the RGB values from an image, and color a canvas using them. But the results come out a bit weird, as not all colors match. I can try to some a more detailed patch in a couple of days, but wanted to ask first the there is any example of how to use the values coming out of [pix_data]: - should the gray value be used? - the middle outlet should send a list of RGB values, but I noticed that instead a list of 4 values comes out. This isn't documented, what is the 4th value? Attached are 2 pictures that should exemplifiy the issue: - rgb.tif - a rgb palette - rgb-conv.tif - the result after my interpretation of the data Best, Joao

1 0

Jack support for 0.46-7 / Arm V7?
by William Huston 31 Dec '15

31 Dec '15

It does not appear this version has Jack support compiled in. Is this correct? & intentional? If so, I guess I have to compile it myself. Just want to make sure. Thanks. -- -- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta)

2 2

Re: [PD] link between C++ and PD
by Dan Wilcox 30 Dec '15

30 Dec '15

I’d also recommend liblo but you’ll need pthreads-win32 as a dependency. If he’s working with Visual Studio and mainly a Windows dev, stick to oscpack as it’s easier to build and use in VS. There have been some recent updates to oscpack, so it’s not dead. That being said, I prefer liblo and wrote a C++ wrapper around it that is inspired by oscpack (as I have used both over the years): https://github.com/danomatika/lopack <https://github.com/danomatika/lopack> -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Dec 30, 2015, at 1:25 PM, pd-list-request(a)lists.iem.at wrote: > > From: IOhannes m zmölnig <zmoelnig(a)iem.at <mailto:zmoelnig@iem.at>> > Subject: Re: [PD] link between C++ and PD > Date: December 30, 2015 at 1:24:50 PM MST > To: pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at> > > > On 12/30/2015 09:18 PM, jma(a)jeanmarie-adrien.net <mailto:jma@jeanmarie-adrien.net> wrote: >> tks ! >> Le 30 déc. 2015 à 19:39, Py Fave <pyfave(a)gmail.com <mailto:pyfave@gmail.com>> a écrit : >> >>> >>> >>> look for an osc library for c++ , >>> there are many >>> >>> >>> i had an experience of this kind , >>> this library was used >>> >>> oscpack -- Open Sound Control packet manipulation library >>> http://www.audiomulch.com/~rossb/code/oscpack <http://www.audiomulch.com/~rossb/code/oscpack> > > i would recommend liblo [1] instead. > it seems to be the most commonly used library these days. > it is also more actively developed than oscpack. > > liblo states that it is an OSC-implementation for "POSIX systems" (which > w32 is not), but afaik it does work on w32. > > mgsd > IOhannes > > [1] https://github.com/radarsat1/liblo <https://github.com/radarsat1/liblo>

1 0

link between C++ and PD
by jma＠jeanmarie-adrien.net 30 Dec '15

30 Dec '15

Hello C natives What is the most straightforward way to have a running C program send data (global variables) to a PD patch for real time control (say a vector of ten floats, 80 times per second), means : what names for fonctions (procedures) in C, and what objects in PD (netreceive ? dumposc ?), all of this on windows... Tks JM PS Although i wrote thousands of lines of C++ in my young age, i dont remember ANYTHING about it now, except semi columns and {braces} or so.

7 10

Weird behavior of [moocow/bytes2any], or not?
by Alexandros Drymonitis 30 Dec '15

30 Dec '15

I'm trying several lists from symbols with [moocow/bytes2any] and the following behavior seems a bit strange to me. The following symbols, converted to numeral lists behave fine: a_float, a_string, string, a_bang, bang The corresponding lists sent to [bytes2any] are: 97 95 102 108 111 97 116 97 95 115 116 114 105 110 103 115 116 114 105 110 103 97 95 98 97 110 103 98 97 110 103 If I send these lists to [bytes2any] it will output the correct messages (a_float, a_string, etc.). The symbol "float" though, which is converted to the list "102 108 11 97 116", when sent to [bytes2any] produces a 0 out the left outlet of the object. I have attached a patch that demonstrates this. The symbols are converted to lists with [list fromsymbol]. I could use [list tosymbol] to create symbols from the lists, but I want to test [bytes2any] in this case. Is this behavior expected or is it a bug?

4 7

"vis 1" message creates hanging atoms
by Liam Goodacre 29 Dec '15

29 Dec '15

Here is a curious little bug that I've been trying to solve for days. If you use the "vis 1" / "vis 0" messages to dynamically open and close a patch, sometimes the atom objects (float or symbol) hang in the GOP area. By hang I mean that a dead copy is created just below the original atom. It doesn't function, but it stays there on the canvas if you move the GOP object, and it can't be selected or deleted. I am attaching a little patch which demonstrates this. My guess is that this has something to do with the grey rectangle that is usually imposed over the GOP area when you open it through the menu. This doesn't work when you use the "vis 1" message, and so the parent canvas must be receiving a TCL command to recreate the float, when it wasn't destroyed in the first place. Does anyone have a clearer idea of what is going on, and, more importantly, how I can work around it? I know that dynamic patching isn't officially supported, but I'm still crossing my fingers for a way to prevent this bug. A few more curiosities: 1. If the abstraction patch is empty apart from the float, the bug doesn't seem to occur. Try deleting the [metro] ad [f] objects in the "nofloat" patch to see this. 2. If I repeat the process by opening and closing through "vis 1" a second time, the first hanging float starts to disappear. This works in the attached demonstration patch, but not in the patch that I'm trying to build. Could this have something to do with the number of other objects, as in point 1?

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
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 December 2015