Pd-list April 2016

pd-list@lists.iem.at

75 participants
106 discussions

Re: [PD] pdlv2: generate lv2 plugins from pd patches
by Pierre Guillot 11 Apr '16

11 Apr '16

That's a great project. I also want to add lv2 support to Camomile but It seems that this is not a priority for Juce and I'm a lost between the Juce interface and the lv2 SDK. I think that Dan is right. It's always better to use locks in C++ because this is integrated in the standard library and cross-platform. Another reason to avoid automatic lock is because most of the time, you want to send messages and process the digital signal jointly. So it would be useless to lock, send the message, unlock, lock, process, unlock. In my C++ interface, all the lock system is implicit and hidden (when I load or delete a patch for example) except for these methods. In fact, the lock system is just a detail, the "libpd layer" that Dan explained is the most important. In the C interface of Camomile, I use an internal instance system that really manages the multiple instances. Nevertheless I'm not sure of the necessity of the ring buffers. It seems to me that it brings some confusion on how the internal mechanism works, like if the methods could be called in parallel while in fact the methods must be called sequentially. But perhaps I don't understand very well the good way to use it or the context where this is necessary. Anyway I 'm glad someone read my email, I thought nobody noticed :) Question: What the GUI part is supposed to do ? That would be an interface to receive the textual messages normally sent to tcl/tk ? Or that would be an interface to manage the template/structure/scalar system ?

2 1

static arrays in object's struct?
by Matt Barber 11 Apr '16

11 Apr '16

I've run across a few objects (e.g. buffir~ in cyclone) which maintain a static array in the object's struct to use as a buffer instead of a getbytes() block. If the array doesn't need to change size, are there reasons not to do this?

2 1

can signal inlets that aren't the main inlet have float or message methods?
by Derek Kwan 11 Apr '16

11 Apr '16

> Are you really sure you want that? These days most Pd-users expect an implicit float-to-signal conversion. This might lead to unexpected (though well-defined) behaviour of your objects. > My advice is to not try hard to break the expectancy of your users. Hello, In normal circumstances, I'd be in 100% agreement with you, the user experience should be consistent throughout the entirety of PD. But in this situation I'm doing work for cyclone, and in particular scope~ accepts a signal in the right inlet for graphing on the Y-axis and a separately a float to change the buffer size and I'm trying to stay as close to the original spec as possible. ===================== Derek Kwan www.derekxkwan.com

7 35

Re: [PD] pdlv2: generate lv2 plugins from pd patches
by Dan Wilcox 09 Apr '16

09 Apr '16

Miller was also looking into adding the ability to launch the gui to libpd. There was a discussion somewhere, I can’t find it right now... -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Apr 8, 2016, at 12:07 PM, pd-list-request(a)lists.iem.at wrote: > > From: Kjetil Matheussen <k.s.matheussen(a)gmail.com <mailto:k.s.matheussen@gmail.com>> > Subject: Re: [PD] pdlv2: generate lv2 plugins from pd patches > Date: April 8, 2016 at 11:08:29 AM MDT > To: Alex <x37v.alex(a)gmail.com <mailto:x37v.alex@gmail.com>> > Cc: "pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>" <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Reply-To: k.s.matheussen(a)notam02.no <mailto:k.s.matheussen@notam02.no> > > > You might have to merge inn libd from upstream though. Don't know how > much work that is. > > On Fri, Apr 8, 2016 at 7:06 PM, Alex <x37v.alex(a)gmail.com <mailto:x37v.alex@gmail.com>> wrote: > Great, I'll look into that when I get some more time! > > On Fri, Apr 8, 2016 at 9:55 AM, Kjetil Matheussen <k.s.matheussen(a)gmail.com <mailto:k.s.matheussen@gmail.com>> wrote: > > > On Fri, Apr 8, 2016 at 6:51 PM, Alex <x37v.alex(a)gmail.com <mailto:x37v.alex@gmail.com>> wrote: > hmm, that is interesting, is libpds simply part of the radium project or is it something you distribute separately? I should look into that. > > It's my branch of libpd on github. You can ignore the libpds part, and > just use libpd as you do already, only that this version of libpd also > provide pd gui. > >

4 12

Re: [PD] Pd-l2ork GUI port Alpha 0
by Dan Wilcox 08 Apr '16

08 Apr '16

Looks good. Very smooth rendering & the zooming works well with my retina screen. Fullscreen also works well. Testing on OSX, just noticed a few things: * On OSX, the first menu item is the name of he application which contains: About, Preferences, settings menus, etc. Looks like the “purrdata” menu actually has the contents of the File menu which, itself, does not exist. The next menu entry is Edit. * The Preferences should be launched with the CMD+, hotkeys. * The Audio preferences tab doesn’t preload the devices. When first launched, the drop down boxes are empty then suddenly fill & adjust the layout. * The Midi preference tab is empty & the only api available is “oss”. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/> > On Apr 8, 2016, at 10:21 AM, pd-list-request(a)lists.iem.at wrote: > > From: Jonathan Wilkes <jancsika(a)yahoo.com <mailto:jancsika@yahoo.com>> > Subject: [PD] Pd-l2ork GUI port Alpha 0 > Date: April 8, 2016 at 8:38:37 AM MDT > To: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>> > Reply-To: Jonathan Wilkes <jancsika(a)yahoo.com <mailto:jancsika@yahoo.com>> > > > Hi list, > Here are some binaries to test out the alpha 0 release for the GUI port of Pd-l2ork.

3 3

listing PD's external platforms
by Liam Goodacre 08 Apr '16

08 Apr '16

There are a lot of platforms for running PD on the web, on tablets, or on something other than the native PD GUI (I lack the proper generic term here, so I'm going with "external platforms"). These days it feels like a new one pops up every few months. I can think of these off the top of my head, but I'm sure there are more: LibPDDroid PartyRJDJMobMuPlatGemmalibHeavy Compilerweb-pd Would someone be interested in compiling a comparison table for these platforms, or does such a list exist already? I'm picturing something like this: NAME----DEVELOPER----OS COMPATIBILITY-----PD EXTERNALS------ACTIVE DEVELOPMENT---ETC LibPD----Steve-------------Linux/Windows-----------Vanilla only-----------Yes RJDJ------Betty--------------IOS/Android---------------Yes----------------------No ETC------ (facts are all wrong here--I've included them just for illustration). I think such a thing would be important because a: it would help new users find the right tools for their own projects and b: it would be a good way of promoting these wonderful products. I think there are already enough of them that we need such a comparison, and there are still likely to be more in the future. I'm happy to help with this project, although I shouldn't be the one to lead it, as I'll only get it wrong. If anyone wants to take it up, please help me find a better term than "external platforms", as both of these words already have multiple meanings in PD.

5 5

Re: [PD] Missing objects/methods in Pd WAS: objects with no alphanumerical names, how to build them?
by Dan Wilcox 08 Apr '16

08 Apr '16

> On Apr 5, 2016, at 5:59 PM, pd-list-request(a)lists.iem.at wrote: > > Joking aside, at least some externals that prove to be very useful or even fundamental (like zexy's sigops or [z~]) could find its way into the core now and then. To me, Pd vanilla seems to be overly conservative in this respect. On the other hand, I like that the set of objects is rather restricted, it's just about a handful of objects which I think are really missing and shouldn't require a user to get an external library. > > And when there are already good externals which do an important job, why not include them? For example, Pd vanilla got its own set of OSC objects recently (nice!), but they are rather awkward to use and have far less functionality then, for example, the mrpeach objects (Miller actually refers to them in the help patch). The answer is maintainability: OF has 3 core members and 10+ affiliated core devs with commit access. Pd has 1 core member with commit access. I feel like OF right now is where PD was circle early 2000s. At some point it will stabilize since so many people rely on it and get tired of bugs and breaking changes introduced by *so* many commits by so many people. IMO the OF core is now way too large and parts of it should be spun off as addons. It makes more sense to have a solid, slim core which you can add functionality to -> externals. This way, we get stability at a (small) loss of convenience by having to add an external. deken will make this relatively painless once the next Pd release comes out. -------- Dan Wilcox @danomatika <https://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>

5 12

$0-abstraction question
by Johan Ericsson 08 Apr '16

08 Apr '16

Dear List, This is my first time writing here so please be gentle. :-) I'm working on a state saving system in vanilla for multiple instances of the same abstraction. I've got a good system up and running where I'm writing and reading to textfile using numerical creation arguments for the abstractions to separate the textfiles from each other. However, it would be a lot easier if the unique four digit $0 digits of the abstraction was saved with the .pd-file and not given a new number on re-booting the patch. There is probably a million scenarios where this behaviour would be not desired that I'm unaware of. But it would be nice to be able to skip giving the abstraction an argument on creation. All best / Johan

3 3

Re: [PD] Pd-list Digest, Vol 133, Issue 36
by Peter Nyboer 08 Apr '16

08 Apr '16

Thanks for setting me straight, IOhannes! Peter > ouch, you are mixing two different build systems. > in brief, you should do > > EITHER > $ cd ~/pd-0.46-7/ > $ ./autogen.sh > $ ./configure --disable-portaudio --disable-portmidi --no-recursion > $ make > $ sudo make install > > OR > $ cd ~/pd-0.46-7/ > $ cd src > $ make -f makefile.gnu > $ sudo make -f makefile.gnu install > > running autotools and then switching to makefile.gnu is discouraged, as > you are effectively building the src/ parts with makefile.gnu and the > extra/ parts with autotools. > > gfmasrd > IOhannes

1 0

pdlv2: generate lv2 plugins from pd patches
by Alex 08 Apr '16

08 Apr '16

Its interesting that Camomile and the updated pdvst were announced in these past weeks as I've been working on pdlv2, a wrapper/parser the generates lv2 plugins from pd patches. https://github.com/x37v/pdLV2/ Its a work in progress, I'm not announcing a 'release' at this time, but its definitely usable and I'd love feedback, help with more example patches, help with new features, etc. It does audio, control and midi: in and out. No GUI yet, though many hosts provide a default GUI [Ardour, jalv, .. ..] Tested/developed on Linux, I don't have lv2 running on Mac so I'm not sure if it would work there or not, I haven't heard of people using it on Windows... Basically the workflow is this: you create a patch that has one or more of: [inlet~], [outlet~], [send $1-lv2-blah], [receive $1-lv2-blah2], midi input or output objects And some a couple messages to define the name and unique URI for your plugin. You then save this patch in a directory in the pdlv2 'plugins' directory and call the patch 'plugin.pd'. Then you run 'make', this runs a script that parses your patch to figure out how to wrap it as an lv2 plugin, then writes the files it needs to do that and builds the lv2 plugin. Anyways, if you're interested take a look at the github link above, feel free to email me at my personal email: alex(a)x37v.info, or contact xnor on freenode/#dataflow -Alex

2 5

← Newer
1
...
5
6
7
8
9
10
11
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 April 2016