Re: [PD] smooth random numbers
On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [pix_alpha]: cannot handle YUV image
I'm trying to use [pix_video] with [pix_alpha] and even though I'm sending [colorspace RGBA( to [pix_video] I get this error message. Can someone point out what I'm missing? Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [pix_alpha]: cannot handle YUV image
Just found it in the FLOSS manuals, I missed the connection between [pix_video] and [pix_rgba] before connecting that to [pix_alpha]...sorry for the hasty post. On Mon, Feb 24, 2014 at 12:14 PM, Alexandros Drymonitis adr...@gmail.comwrote: I'm trying to use [pix_video] with [pix_alpha] and even though I'm sending [colorspace RGBA( to [pix_video] I get this error message. Can someone point out what I'm missing? Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
Sorry, forgot ta add [change -1] after the [i]. I thought this was meant to be used with a MIDI signal - maybe I got that wrong? Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Montag, 24. Februar 2014 10:34 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] ERROR: -35 in GraphicsExportSetOutputFile() GEM: Unable to save image to 'gradient00001.tif'
Yet another question regarding Gem. I'm connecting the outlet of [circle] (which is being rendered in a Gem chain) to the first inlet of [pix_write] and when I send a bang to [pix_write] I get this error and, obviously, no image is being saved. The object's help patch is not helping me thoroughly to be honest. What kind of messages do I have to send to [pix_write] if for example I want to save a .jpg? And of course, why doesn't it save any image? I'm on OS X 10.8.5 with Pd-extended-0.43.4 Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Mon, 2014-02-24 at 13:35 +0100, Ingo wrote: Sorry, forgot ta add [change -1] after the [i]. I thought this was meant to be used with a MIDI signal - maybe I got that wrong? Yes, it is. I'm nit-picking here. The patch you posted before also works, even without the [change -1]. But even adding the [change -1] doesn't address the issues I mentioned. On a fast ramp, it still misses some values and it still suffers from jitter. It's only details I'm talking about here, yes, but since you decided to remove the features from my version, I hoped to be able to illustrate them with words. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Montag, 24. Februar 2014 10:34 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
Roman, are you using MIDI in theory or real life? Jitter is MIDI's alias name. In practice MIDI data is being reduced as much as possible to avoid overloading the MIDI bus and in return causing serious timing problems or even missing data. Since I would not expect this signal to be the only one through the MIDI interface I would actually reduce the data on fast changes even drastically more. All (decent) MIDI receiving devices interpolate between the values in order to avoid zipper noise. I see your point - in fact I had the same thought that you had at first! I dropped it right away. Working on a daily basis with MIDI I know that this is a waste of time. Actually: I would add a [speedlim 5] to reduce data further and you still wouldn't hear anything unusual. That reminds me a little of people asking for 14-bit pitchbend. It would take about 11 seconds to move the pitchbend wheel on a keyboard from the bottom to the top. Even a 7-bit pitchbend takes more that 80 ms sending all values. It's impossible to play music with a precise timing like this! In practice a very fast volume change going from 0 - 127 usually gets reduced to 3-5 numbers in order to allow additional controllers like pitchbend and aftertouch to be sent at the same time and still keep the note on jitter within a range of maybe 3-8 ms (plus the jitter of the interface itself). And BTW - why would random need extra precision? Doesn't the word random say it all? Another neglected thing is the curve that the data change should have. That would obviously require some extra calculation. I don't remember reading anything about that in the original posting, though. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Montag, 24. Februar 2014 14:14 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers On Mon, 2014-02-24 at 13:35 +0100, Ingo wrote: Sorry, forgot ta add [change -1] after the [i]. I thought this was meant to be used with a MIDI signal - maybe I got that wrong? Yes, it is. I'm nit-picking here. The patch you posted before also works, even without the [change -1]. But even adding the [change -1] doesn't address the issues I mentioned. On a fast ramp, it still misses some values and it still suffers from jitter. It's only details I'm talking about here, yes, but since you decided to remove the features from my version, I hoped to be able to illustrate them with words. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Montag, 24. Februar 2014 10:34 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
They have an SDK, so I imagine you can get the data out and send it over OSC. At least thats my plan when I get my dev Myo … :D From: Richie Cyngler glitch...@gmail.com Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wise simonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ERROR: -35 in GraphicsExportSetOutputFile() GEM: Unable to save image to 'gradient00001.tif'
Hi, I understand you're trying to render your circle to an image file, you should then have a look at pix_snap. pix_write needs pixels to write, a circle has no pixel data. pix_snap will make a snapshot of your 3D scene (your circle), this snapshot is pixels that you can then write to an image file using pix_write. 2014-02-24 13:53 GMT+01:00 Alexandros Drymonitis adr...@gmail.com: Yet another question regarding Gem. I'm connecting the outlet of [circle] (which is being rendered in a Gem chain) to the first inlet of [pix_write] and when I send a bang to [pix_write] I get this error and, obviously, no image is being saved. The object's help patch is not helping me thoroughly to be honest. What kind of messages do I have to send to [pix_write] if for example I want to save a .jpg? And of course, why doesn't it save any image? I'm on OS X 10.8.5 with Pd-extended-0.43.4 Thanks ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ERROR: -35 in GraphicsExportSetOutputFile() GEM: Unable to save image to 'gradient00001.tif'
hello, Le 24/02/2014 16:49, Etienne Landon a écrit : Hi, I understand you're trying to render your circle to an image file, you should then have a look at pix_snap. pix_write needs pixels to write, a circle has no pixel data. pix_snap will make a snapshot of your 3D scene (your circle), this snapshot is pixels that you can then write to an image file using pix_write. your messing pix_write and pix writer. pix_write should do what Alexandros wants. to write a jpg file send a message [file name 99 cheers c 2014-02-24 13:53 GMT+01:00 Alexandros Drymonitis adr...@gmail.com mailto:adr...@gmail.com: Yet another question regarding Gem. I'm connecting the outlet of [circle] (which is being rendered in a Gem chain) to the first inlet of [pix_write] and when I send a bang to [pix_write] I get this error and, obviously, no image is being saved. The object's help patch is not helping me thoroughly to be honest. What kind of messages do I have to send to [pix_write] if for example I want to save a .jpg? And of course, why doesn't it save any image? I'm on OS X 10.8.5 with Pd-extended-0.43.4 Thanks ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ERROR: -35 in GraphicsExportSetOutputFile() GEM: Unable to save image to 'gradient00001.tif'
You're right, my mistake 2014-02-24 17:06 GMT+01:00 Cyrille Henry c...@chnry.net: hello, Le 24/02/2014 16:49, Etienne Landon a écrit : Hi, I understand you're trying to render your circle to an image file, you should then have a look at pix_snap. pix_write needs pixels to write, a circle has no pixel data. pix_snap will make a snapshot of your 3D scene (your circle), this snapshot is pixels that you can then write to an image file using pix_write. your messing pix_write and pix writer. pix_write should do what Alexandros wants. to write a jpg file send a message [file name 99 cheers c 2014-02-24 13:53 GMT+01:00 Alexandros Drymonitis adr...@gmail.commailto: adr...@gmail.com: Yet another question regarding Gem. I'm connecting the outlet of [circle] (which is being rendered in a Gem chain) to the first inlet of [pix_write] and when I send a bang to [pix_write] I get this error and, obviously, no image is being saved. The object's help patch is not helping me thoroughly to be honest. What kind of messages do I have to send to [pix_write] if for example I want to save a .jpg? And of course, why doesn't it save any image? I'm on OS X 10.8.5 with Pd-extended-0.43.4 Thanks ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward. That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with both his goals and ours. -- Dan Wilcox danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
From: Dan Wilcox [mailto:danomat...@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward. That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with
Re: [PD] libpd separating gui from core
So let's just take a concrete example: $@ syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in the core. This is just an example-- there is a whole category of features which require changes to core code like this one. If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it. -Jonathan On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic i...@vt.edu wrote: From:Dan Wilcox [mailto:danomat...@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use
Re: [PD] libpd separating gui from core
Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd. As we do in OpenFrameworks, I've started a PiratePad for general ideas/requirements. Feel free to add to this: http://piratepad.net/PureData-middle-ground-ideas On Mon, Feb 24, 2014 at 2:44 PM, Jonathan Wilkes jancs...@yahoo.com wrote: So let's just take a concrete example: $@ syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in the core. This is just an example-- there is a whole category of features which require changes to core code like this one. If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it. -Jonathan On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic i...@vt.edu wrote: *From:* Dan Wilcox [mailto:danomat...@gmail.com] *Sent:* Monday, February 24, 2014 11:34 AM *To:* Ivica Bukvic *Cc:* Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann *Subject:* Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then
Re: [PD] libpd separating gui from core
Oops-- by arguments of the parent I mean arguments of the parent abstraction. -Jonathan On Monday, February 24, 2014 2:44 PM, Jonathan Wilkes jancs...@yahoo.com wrote: So let's just take a concrete example: $@ syntax. It is a dollarsign variable in Pd-l2ork (and maybe in Pd-extended-- can't remember) and it expands to the incoming arguments. In an object box this expands to the arguments of the parent. The code for this feature affects Pd's message parser, which is in the core. This is just an example-- there is a whole category of features which require changes to core code like this one. If you have a description of a democratic development process that can implement such a feature by wrapping Pd Vanilla in a GUI wrapper, document how it works, and if it's maintainable I'll help you implement it. -Jonathan On Monday, February 24, 2014 1:56 PM, Ivica Ico Bukvic i...@vt.edu wrote: From:Dan Wilcox [mailto:danomat...@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why
Re: [PD] ERROR: -35 in GraphicsExportSetOutputFile() GEM: Unable to save image to 'gradient00001.tif'
Hm, for some reason none of the two works. Neither with pix_snap, nor without but sending [file name 99( to [pix_write] (replacing name with whatever name I wanna give to the file). I'm still getting the same error message. On Mon, Feb 24, 2014 at 6:17 PM, Etienne Landon landon.etie...@gmail.comwrote: You're right, my mistake 2014-02-24 17:06 GMT+01:00 Cyrille Henry c...@chnry.net: hello, Le 24/02/2014 16:49, Etienne Landon a écrit : Hi, I understand you're trying to render your circle to an image file, you should then have a look at pix_snap. pix_write needs pixels to write, a circle has no pixel data. pix_snap will make a snapshot of your 3D scene (your circle), this snapshot is pixels that you can then write to an image file using pix_write. your messing pix_write and pix writer. pix_write should do what Alexandros wants. to write a jpg file send a message [file name 99 cheers c 2014-02-24 13:53 GMT+01:00 Alexandros Drymonitis adr...@gmail.commailto: adr...@gmail.com: Yet another question regarding Gem. I'm connecting the outlet of [circle] (which is being rendered in a Gem chain) to the first inlet of [pix_write] and when I send a bang to [pix_write] I get this error and, obviously, no image is being saved. The object's help patch is not helping me thoroughly to be honest. What kind of messages do I have to send to [pix_write] if for example I want to save a .jpg? And of course, why doesn't it save any image? I'm on OS X 10.8.5 with Pd-extended-0.43.4 Thanks ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
I think Miller's puredata is awesome. more than 20 years ago I wrote my own assembly routines as well as c++ for an analog devices 32 ch board for waterplant control software , but ended up using the factory drivers instead when they came out for this software http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html. reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. I ought do dig into the programming part of pd . I read a lot of the code and it's kinda starting to sink in how to write an external, it's not quite like on the tip of my toungue yet though. On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 02/24/2014 03:03 PM, Dan Wilcox wrote: Exactly. If we can build a list of things that should/could be in the core, then we have a starting place to see if there is a way to work into into either vanilla or a wrapper like libpd. Let's just focus on a single feature-- $@-- and assume that there is widespread desire for such a feature by most Pd users. How do we put this feature into a wrapper like libpd? The only thing I can think of is as part of a patch set that get applied to core Vanilla, and that's hard to maintain. As for working stuff into Vanilla-- that's Miller's personal version of Pd, and I've never once seen him state that it's the reference client, or that it's at the top of any hierarchy. All I've seen is passive-aggressive statements from other devs on this list who say, You'll have to ask Miller if you want to get 'whatever' in Vanilla, when I ask about the kind of issues you're talking about. Of course I can't be certain but I'd guess that style of non-development is probably one of the biggest sources of your frustration. But I really will help you implement whatever it is you think improves sustainable development for Pd. I really, really don't want to extract patches from the 1000+ commits in Pd-l2ork (granted the core/non-graphical changes would be fewer), but I'll help you do it if that's the path you want to take. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
On 25/02/14 02:28, Dan Wilcox wrote: They have an SDK, so I imagine you can get the data out and send it over OSC. At least thats my plan when I get my dev Myo … :D then they aren't saying go away after all ... some data is available, presumably already analysed which would be quick and easy to use, at least for the pre-defined gestures. What is the pricing? From: Richie Cynglerglitch...@gmail.com Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wisesimonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
$150. I can't find the link right now but the article I read previously inferred that raw data will not be available rather a set of pre-defined gestures which is why I was wondering if anyone was working with or knew more. On Tue, Feb 25, 2014 at 12:49 PM, Simon Wise simonzw...@gmail.com wrote: On 25/02/14 02:28, Dan Wilcox wrote: They have an SDK, so I imagine you can get the data out and send it over OSC. At least thats my plan when I get my dev Myo ... :D then they aren't saying go away after all ... some data is available, presumably already analysed which would be quick and easy to use, at least for the pre-defined gestures. What is the pricing? From: Richie Cynglerglitch...@gmail.com Ha! Excellent point, I guess it's the pirate me interested in their tech but refusing to accept their terms. The original Kinect was packaged similarly and cracked within what weeks if not days? Although granted that was I think unique technology at the time. On Sun, Feb 23, 2014 at 4:05 PM, Simon Wisesimonzw...@gmail.com wrote: On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than a set of predetermined gestures. Anyone else curious or have more info about this device? if they are saying go away! that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list -- Richie www.glitchpop.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
