Re: [PD] [PD-announce] Chocolate et Coffee
Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release. Joao suggestions : - The properties window will have a fixed size. - We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property. - The id name becomes receive symbol and there's also an send symbol. IOhannes suggestions : - The c/tcl library is now named CicmWrapper (The repository name will change with the next release) - If it seems better to change the libray name, Chocolate can become CicmGUI ? About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ? To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller. If we want to replace the vanilla GUIs, two suggestions for the moment : - We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts). - We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes. Cheers 2014/1/10 Jonathan Wilkes jancs...@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote: I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the dupes IOhannes cites already be included in Pd Vanilla after over a decade now? Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about dupes. Then you ship the library, and it just works without users having to find other libraries. -Jonathan On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass. On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpier...@gmail.comwrote: Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release. Joao suggestions : - The properties window will have a fixed size. - We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property. - The id name becomes receive symbol and there's also an send symbol. IOhannes suggestions : - The c/tcl library is now named CicmWrapper (The repository name will change with the next release) - If it seems better to change the libray name, Chocolate can become CicmGUI ? About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ? To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller. If we want to replace the vanilla GUIs, two suggestions for the moment : - We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts). - We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes. Cheers 2014/1/10 Jonathan Wilkes jancs...@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote: I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the dupes IOhannes cites already be included in Pd Vanilla after over a decade now? Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about dupes. Then you ship the library, and it just works without users having to find other libraries. -Jonathan On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ 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] [PD-announce] Chocolate et Coffee
Well, backwards compatibility can have reasonable limitations and perhaps this is one. On Jan 13, 2014, at 6:18 AM, i go bananas hard@gmail.com wrote: i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass. On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpier...@gmail.com wrote: Hi, I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release. Joao suggestions : - The properties window will have a fixed size. - We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property. - The id name becomes receive symbol and there's also an send symbol. IOhannes suggestions : - The c/tcl library is now named CicmWrapper (The repository name will change with the next release) - If it seems better to change the libray name, Chocolate can become CicmGUI ? About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ? To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller. If we want to replace the vanilla GUIs, two suggestions for the moment : - We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts). - We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...). Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes. Cheers 2014/1/10 Jonathan Wilkes jancs...@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote: I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the dupes IOhannes cites already be included in Pd Vanilla after over a decade now? Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about dupes. Then you ship the library, and it just works without users having to find other libraries. -Jonathan On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox @danomatika 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
As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. Conceptually, I know the tcl/tk-ism for the canvas, object positions, etc are fully baked into how everything works and I don't see a reason to try and change that. Again, perhaps the easiest method would be formalize those conventions via function wrappers which work 1-1 within the existing tcl/tk gui but perhaps require some adaptation for other gui frameworks. In other words, trying to find the least intrusive way to do this as I believe Martin has already done with the existing work in libpd. I truly respect Miller's work with Pure Data and understand the need to move slowly to maintain the highest possible backwards compatibility with all existing computer music pieces made in Pure Data. So far libpd has proven we can abstract some of the Pd core functionality without affecting Pd-vanilla, so I think it's possible to look for the next steps. The recent point of not being able to run GEM an audio heavy patch on the same pd instance is really not a fault of the core but of the gui implementation. I have used libpd within OpenFrameworks for a number of computer vision + sound apps so I know it's definitely possible. Again, I'm only theorizing. I'm pretty familiar with how the iem guis are coded after emulating them in ObjC for PdParty, but I haven't delved into the nit and grit of the core yet. At least I can say now that the paradigms make more sense. As reference, last summer I updated some pretty hairy C code in RTCmix so that it would build as a library on Windows in MinGW: https://github.com/CreativeInquiry/RTcmix I have access to a triple boot machine to test code on Win/Mac/Linux which I regular use for OpenFrameworks work. So if I seriously gave this a shot, it wouldn't be a look, it works on my machine, but I haven't tried it on OS A, B, Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] groove machine how to: keep metro and a loop in sync
Hi Filippo, You're welcome. You probably forgot to reply-to-all, but I added pd-list to the conversation. I hope you don't mind, but I do this ... a) to prevent ten people to answer the same question, not knowing that nine others are or have been spending time to do exactly the same, and b) for the archive. It's annoying if you have a problem, search the web, and do find your question, but not the answer, since it is not made public. On Mon, Jan 13, 2014 at 5:48 PM, Filippo Beck Peccoz m...@fbpsound.comwrote: Hi Funs and thanks a lot for the message! Sorry if I'm launching noob questions at you, but so far I've only used a tabplay~ object and a metro with a set bpm, and triggered both of them at the same time- this is obviously not ideal..although it almost works the fade into and out of the drum loop should be perfectly timed, especially for this kind of application. I am, however, a little lost as to how extrapolate bar/beat information from the objects you suggested. I'm sure it's super easy and I'm missing something obvious. Why do you put the 1000 in the message that goes to the line object? I assumed you were reading the table with [tabread~] or [tabread4~]. For looping purposes it is common to use [phasor~] in combination with one of these two. If the loop should last 1 second (1000 ms) its frequence should be 1 Hertz (cycle per second). So the equivalent for the argument `1' for [phasor~] would be `1000' (milliseconds) for [line~]. Translation is done using the following function: y = 1000 / x, where x is the length of the time interval in ms and y the frequency in Hz (note that x = 1000 / y). This one second sample was just an example. [soundfiler] outputs the length of your sound sample in dsp samples. I don't understand what you mean by `bar/beat information', for I can't precisely imagine what you are building. Regards, Funs ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Chocolate et Coffee
is it possible/feasible to add a switch so that "old" objects don't get replaced by the new ones? e.g. by analysing the parameters of the creation objects? if so, and someone delivers the code for this (I don't know how to do it myself), there might be a better chance of these objects making it into vanilla. (or not?)Well, backwards compatibility can have reasonable limitations and perhaps this is one.On Jan 13, 2014, at 6:18 AM, i go bananas hard@gmail.com wrote:i very much doubt miller will include stuff in vanilla that's not backwards compatible. seeing as how these objects don't even work with my (relatively) recent 0.42.5 version, i can't see how they'd pass. On Mon, Jan 13, 2014 at 6:00 PM, Pierre Guillot guillotpier...@gmail.com wrote: Hi,I may have been sensitive, I needed 2 days break, sorry. If we focus on the important facts, I received really constructive feedbacks and I've been able to improve the library for the next release. Joao suggestions :- The properties window will have a fixed size.- We can set (in the code) if we want a color picker, checkbox, menu or textfield for each property.- The id name becomes receive symbol and there's also an send symbol. IOhannes suggestions :- The c/tcl library is now named CicmWrapper (The repository name will change with the next release)- If it seems better to change the libray name, Chocolate can become CicmGUI ? About the right click during runmode, It's possible to change it but I don't really like it. Do you think that's really important ?To include in Pd-ext, it's possible to only include Chocolate, I just have to replace all the c.prepend and c.loadmess with prepend and init. I received mails and some users like c.patcherargs and the double click of the coffee objects but they can download and add the library manually. To include in Vanilla, you're right, the best is to ask to Miller.If we want to "replace" the vanilla GUIs, two suggestions for the moment :- We keep the the vanilla GUIs and we just replace the shortcut, we won't have any problem to load previous patchs and users will use the new GUI for their new patchs (Secure and easy to do, we can also have an option to replace or not the vanilla shortcuts). - We overwrite the vanilla classes then every objects will replaced but the users will lose the properties (size, font, color, etc...).Another idea is to add a menu option or to offer 2 libraries with one that overwrite classes. Cheers2014/1/10 Jonathan Wilkes jancs...@yahoo.com On 01/10/2014 12:50 PM, Dan Wilcox wrote: I don't have any plans, I was only responding in a hypothetical manner. I'm busy on a show right now and can't do pd dev. A better person to ask is Miller ... I must have misunderstood-- the way you wrote that made it sound like there is a process by which the community gets things included into Pd Vanilla. If such a process existed wouldn't one of the "dupes" IOhannes cites already be included in Pd Vanilla after over a decade now? Instead, I think Pierre has taken the only sensible approach to making a library that works with both Pd-Vanilla and Pd-extended. You simply code up the stuff that's been missing forever-- some of it probably in less time than it takes to respond to questions about "dupes". Then you ship the library, and it "just works" without users having to find other libraries. -Jonathan On Jan 10, 2014, at 12:48 PM, Jonathan Wilkes jancs...@yahoo.com wrote: What is your plan for getting the necessary features into Vanilla so that such dupes are no longer necessary to include in a library like this? Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Dan Wilcox@danomatikadanomatika.comrobotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] groove machine how to: keep metro and a loop in sync
I'm not super-familiar with the guts of Pd's scheduling system, but I think that if one metro object outputs a bang to separate tabplay~ objects, both should start playing at exactly the same time. While using line~ or phasor~ can lead to more robust samplers (allowing you to adjust playback speed, etc.), I think tabplay~ should be perfectly adequate for this patch. Filippo, it would help us to see your patch and the samples you are using, so that we could get a better idea of how the loops are getting out of sync. -Brian On Mon, Jan 13, 2014 at 12:45 PM, Funs Seelen funssee...@gmail.com wrote: Hi Filippo, You're welcome. You probably forgot to reply-to-all, but I added pd-list to the conversation. I hope you don't mind, but I do this ... a) to prevent ten people to answer the same question, not knowing that nine others are or have been spending time to do exactly the same, and b) for the archive. It's annoying if you have a problem, search the web, and do find your question, but not the answer, since it is not made public. On Mon, Jan 13, 2014 at 5:48 PM, Filippo Beck Peccoz m...@fbpsound.comwrote: Hi Funs and thanks a lot for the message! Sorry if I'm launching noob questions at you, but so far I've only used a tabplay~ object and a metro with a set bpm, and triggered both of them at the same time- this is obviously not ideal..although it almost works the fade into and out of the drum loop should be perfectly timed, especially for this kind of application. I am, however, a little lost as to how extrapolate bar/beat information from the objects you suggested. I'm sure it's super easy and I'm missing something obvious. Why do you put the 1000 in the message that goes to the line object? I assumed you were reading the table with [tabread~] or [tabread4~]. For looping purposes it is common to use [phasor~] in combination with one of these two. If the loop should last 1 second (1000 ms) its frequence should be 1 Hertz (cycle per second). So the equivalent for the argument `1' for [phasor~] would be `1000' (milliseconds) for [line~]. Translation is done using the following function: y = 1000 / x, where x is the length of the time interval in ms and y the frequency in Hz (note that x = 1000 / y). This one second sample was just an example. [soundfiler] outputs the length of your sound sample in dsp samples. I don't understand what you mean by `bar/beat information', for I can't precisely imagine what you are building. Regards, Funs ___ 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 01/13/2014 09:32 AM, Dan Wilcox wrote: As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. I think by DSP core you're referring to: * DSP graph stuff * message dispatching system * various widgetbehaviors and data structures parentwidgetbehaviors * all the gui logic in g_editor.c * gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting Is this correct? In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Check for batch and/or nogui mode from Patch
Hi, is there a way to get information on whether Pd has been started with -batch or -nogui from inside a patch? I am trying to make unit tests by starting a Pd instance in batch mode from Python, and comparing the output from [stdout] to the desired result, and I want Pd to close itself via [; pd quit(. When Pd is not running in batch mode, then I want to stop this message from being sent with a [spigot], something like: [loadbang] | [message for object( | [object-to-test] | [t b a] | | | [stdout] | | [test-for-batch-mode] | | [spigot] | [; pd quit( Thanks, Thomas -- We left all that stuff out. If there's an error, we have this routine called panic, and when it is called, the machine crashes, and you holler down the hall, 'Hey, reboot it.' (Dennis Ritchie) http://www.residuum.org/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] groove machine how to: keep metro and a loop in sync
Thank you Funs for pointing the reply-all thing out, sorry! Now sending to the whole list :) I'd be happy to keep tabplay for this since it seems solid and easy to work with, but will have to look deeper into the phasor~ solution, it looks very interesting. Brian, thanks for your suggestions, and here is the patch with a test loop. https://fbpserver.dyndns.org/pydio/data/public/366c84.php It's messy but I commented a bit to show the way- I'm still thinking about how to integrate some sort of dynamic difficulty level that gradually introduces longer stretches of silence, but that is not hardcoded like it is here. After a while, the fade kicks in just a tad early, it seems to me. The basic functions are there, but it's weird that it seems to slide a bit. Or am I going crazy? :) Cheers, Filippo Filippo Beck Peccoz Game Audio www.fbpsound.com Twitter: @fbpsound Skype: fbpsound Mobile: +49-(0)1520-4004143 Studio: +49-(0)89-80033204 Fax: +49-(0)89-99752164 On Jan 13, 2014, at 7:22 PM, Brian Fay ovaltinevor...@gmail.com wrote: I'm not super-familiar with the guts of Pd's scheduling system, but I think that if one metro object outputs a bang to separate tabplay~ objects, both should start playing at exactly the same time. While using line~ or phasor~ can lead to more robust samplers (allowing you to adjust playback speed, etc.), I think tabplay~ should be perfectly adequate for this patch. Filippo, it would help us to see your patch and the samples you are using, so that we could get a better idea of how the loops are getting out of sync. -Brian On Mon, Jan 13, 2014 at 12:45 PM, Funs Seelen funssee...@gmail.com wrote: Hi Filippo, You're welcome. You probably forgot to reply-to-all, but I added pd-list to the conversation. I hope you don't mind, but I do this ... a) to prevent ten people to answer the same question, not knowing that nine others are or have been spending time to do exactly the same, and b) for the archive. It's annoying if you have a problem, search the web, and do find your question, but not the answer, since it is not made public. On Mon, Jan 13, 2014 at 5:48 PM, Filippo Beck Peccoz m...@fbpsound.com wrote: Hi Funs and thanks a lot for the message! Sorry if I'm launching noob questions at you, but so far I've only used a tabplay~ object and a metro with a set bpm, and triggered both of them at the same time- this is obviously not ideal..although it almost works the fade into and out of the drum loop should be perfectly timed, especially for this kind of application. I am, however, a little lost as to how extrapolate bar/beat information from the objects you suggested. I'm sure it's super easy and I'm missing something obvious. Why do you put the 1000 in the message that goes to the line object? I assumed you were reading the table with [tabread~] or [tabread4~]. For looping purposes it is common to use [phasor~] in combination with one of these two. If the loop should last 1 second (1000 ms) its frequence should be 1 Hertz (cycle per second). So the equivalent for the argument `1' for [phasor~] would be `1000' (milliseconds) for [line~]. Translation is done using the following function: y = 1000 / x, where x is the length of the time interval in ms and y the frequency in Hz (note that x = 1000 / y). This one second sample was just an example. [soundfiler] outputs the length of your sound sample in dsp samples. I don't understand what you mean by `bar/beat information', for I can't precisely imagine what you are building. Regards, Funs ___ 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
Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 01/13/2014 09:32 AM, Dan Wilcox wrote: As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. I think by DSP core you're referring to: * DSP graph stuff * message dispatching system * various widgetbehaviors and data structures parentwidgetbehaviors * all the gui logic in g_editor.c * gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting Is this correct? Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact? Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Check for batch and/or nogui mode from Patch
hello, the most simple solution is to add a message at startup : pd -batch -send testquit bang [loadbang] | [message for object( | [object-to-test] | [t b a] | | | [stdout] | | [r testquit] | | | [1 | | [spigot 0] | [; pd quit( cheers c Le 13/01/2014 20:26, Thomas Mayer a écrit : Hi, is there a way to get information on whether Pd has been started with -batch or -nogui from inside a patch? I am trying to make unit tests by starting a Pd instance in batch mode from Python, and comparing the output from [stdout] to the desired result, and I want Pd to close itself via [; pd quit(. When Pd is not running in batch mode, then I want to stop this message from being sent with a [spigot], something like: [loadbang] | [message for object( | [object-to-test] | [t b a] | | | [stdout] | | [test-for-batch-mode] | | [spigot] | [; pd quit( Thanks, Thomas ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Check for batch and/or nogui mode from Patch
On Mon, 2014-01-13 at 20:26 +0100, Thomas Mayer wrote: Hi, is there a way to get information on whether Pd has been started with -batch or -nogui from inside a patch? Though I consider Cyrille's approach the clean way for your specific purpose, there is also a way to check for '-batch' without help from outside. Measure [delay 1000] with [realtime] and if the result is orders of magnitude smaller than '1000' (say 0.4), Pd has most likely been started with '-batch' (assuming it didn't do much during the 1000ms logical time). Roman ___ 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 01/13/2014 03:11 PM, Dan Wilcox wrote: Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: On 01/13/2014 09:32 AM, Dan Wilcox wrote: As Hans has proposed for years, IMO this is really the only way to perhaps solve the PD gui development doesn't move fast enough problem in the long term. In this case, Miller would have the core (in libpd) the pd-vanilla wrapper gui formally separated while everyone else can then use the same libpd core within other flavors. The DSP core is the heart and soul and I see no reason to try and change that in any way. Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. Then what do you think of $@ or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks? On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: #2 is hard. Where would you start and how would you proceed? I think what makes sense is to list out the main interfaces to the DSP core that are currently being used by TCL. I think by DSP core you're referring to: * DSP graph stuff * message dispatching system * various widgetbehaviors and data structures parentwidgetbehaviors * all the gui logic in g_editor.c * gui queuing stuff, array selection/manipulation logic, mouse motion callbacks, and probably other things I'm forgetting Is this correct? Yes, minus the widgets and gui queuing stuff, etc. I'm talking about finding a way to separate the strictly gui stuff from the DSP graph. I recognize that some of that is required, so I'm trying to think pragmatically. Obviously you're a better judge of that as you have more experience with the code in the area. In the simplest case, we could literally create wrapper functions which emulate the tcl argument lists. libpd currently wraps the formal message sending, midi, processing areas. I think now we need to see if it's possible to wrap the DSP graph editing/manipulation, canvas, patch loading/saving, etc. I'm not clear on what libpd actually includes. For example, does all the logic from g_editor remain intact? Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive): * displacing selected objects requires a message from core - gui for every single object that is selected. Here's such a message for displacing [clip] by one pixel: .x9892638.c move .x9892638.t9896128 1 0 .x9892638.c coords .x9892638.t9896128R 40 37 72 54 .x9892638.c itemconfigure .x9892638.t9896128R -dash .x9892638.c coords .x9892638.t9896128o0 40 53 47 54 .x9892638.c coords .x9892638.t9896128i0 40 37 47 38 .x9892638.c coords .x9892638.t9896128i1 52 37 59 38 .x9892638.c coords .x9892638.t9896128i2 65 37 72 38 Compare to Pd-l2ork for the same action: .xa261e08.c move selected 1 0 And here's the Pd-l2ork message for displacing 100 selected [clip] objects by one pixel: .xa261e08.c move selected 1 0 (Compare to 36K of messages that Vanilla must send in order to do the same thing.) It's even worse for Put menu arrays. Just fire up Pd with the -d 3 flag and look at what gets sent from core - gui every time you move the array one pixel. * Vanilla only has a single undo level. So if you want the gui with libpd to be at all modern you'll have to either a) add undo facilities to the core or b) code up a completely separate model of Pd objects in whatever language your gui uses. matju took route b in DesireData-- if you can still dl it, look in poe.tcl-- it's a tcl object-oriented library that keeps track of objects/canvases/etc. (Tcl/Tk 8.6 includes an object-oriented library in the core, so maybe this is easier to do now.) Ivica took route a in Pd-l2ork. Maybe there's some easier way to do this, but if you go a different route make sure it's maintainable. * Most of the vanilla stuff doesn't even make use of the sys_queuegui functionality which (as far as I understand it) can filter out needless calls to the gui. * If you don't want to make changes to the core libpd stuff, the problems mentioned above still cause dropouts. The core is sending (and the gui is receiving) enormous amounts of data over a socket while the audio engine is trying to meet deadlines.
Re: [PD] libpd separating gui from core
On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 01/13/2014 03:11 PM, Dan Wilcox wrote: Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. Then what do you think of $@ or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks? Those would definitely be nice to have. I don't know what $@ refers to, is it the object arguments as a list? On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive): [snip] That's all good info to know, thanks. I'd imagine libpd would't need to handle *move functions though. Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] UDP vs TCP, for OSC networking
Hi list, I'm sending data between two computers, in every 10ms. For fast networking, TCP is better result? I don't know which is better. Most tutorials show example of OSC with UDP. Why? Thanks, Jong ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? On Jan 13, 2014, at 5:14 PM, Dan Wilcox danomat...@gmail.com wrote: Does the dsp graph rely on positioning? I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UDP vs TCP, for OSC networking
hi, i'm not an expert on PD but my feeling was that TCP does error checking while UDP does not, and that at least is one reason why TCP should be slower than UDP in a typical networking situation. scott On Mon, Jan 13, 2014 at 2:20 PM, Jonghyun Kim agitato...@gmail.com wrote: Hi list, I'm sending data between two computers, in every 10ms. For fast networking, TCP is better result? I don't know which is better. Most tutorials show example of OSC with UDP. Why? Thanks, Jong ___ 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] Check for batch and/or nogui mode from Patch
Hi, On 13.01.2014 21:20, Cyrille Henry wrote: hello, the most simple solution is to add a message at startup : pd -batch -send testquit bang thanks, that worked liked a charm. Minor correction though: The command line is pd -batch -send testquit bang [loadbang] | [message for object( | [object-to-test] | [t b a] | | | [stdout] | | [r testquit] | | | [1 | | [spigot 0] | [; pd quit( And now: Unit testing PuREST JSON, Thomas -- Ich komme aus dem Staunen nicht heraus. Dann bleib halt drin, du Seppel (Dietmar Dath - Die Abschaffung der Arten) http://www.residuum.org/ ___ 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 01/13/2014 05:14 PM, Dan Wilcox wrote: On Jan 13, 2014, at 5:05 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: On 01/13/2014 03:11 PM, Dan Wilcox wrote: Woops, forgot the reply-all. On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: Sorry, I don't know quite what you're referring to here. The only two examples I gave-- $@ and [initbang] wouldn't change anything in the DSP core. I wasn't referring to anything in particular, only in general. Then what do you think of $@ or [initbang]? Are there good reasons for them not being in the core? What about infinite undo? Or symbols that don't cause memory leaks? Those would definitely be nice to have. I don't know what $@ refers to, is it the object arguments as a list? On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: Yes. Everything is still there. It merely abstracts sending messages and midi into and out of the libpd instance. I don't see why we couldn't do the same with what's needed by an external gui wrapper around it. Hm... I didn't realize that. That being the case, you could certainly go ahead and figure out some interim way of sending and parsing tcl messages using whichever gui toolkit you prefer. However, it's worth understanding a bit about why Pd-l2ork has diverged somewhat from the code you'd be wrapping (in no particular order, and definitely not exhaustive): [snip] That's all good info to know, thanks. I'd imagine libpd would't need to handle *move functions though. Does the dsp graph rely on positioning? It does for [inlet~] and [outlet~] And for message dispatching [inlet] and [outlet]. There are also objects like [cnv] and some externals which can use and report object position in the flow of an object chain. I thought only via connections. I'd imagine the gui wrapper should only worry about positioning and simply update those changes when saving. Dan Wilcox @danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] UDP vs TCP, for OSC networking
Pretty much. TCP ensures that every packet gets there intact. You have a back and forth between the server of the packet and the client to make sure. UDP just sends the packet where you ask, and doesn't confirm whether it makes it at all. Generally for most OSC use the number of packets you're sending isn't going to be high enough that packet loss is an issue and most people use UDP since it will be faster. Then if you're running into packet loss, for whatever reason, try switching to TCP. On Mon, Jan 13, 2014 at 2:44 PM, Scott R. Looney scottrloo...@gmail.com wrote: hi, i'm not an expert on PD but my feeling was that TCP does error checking while UDP does not, and that at least is one reason why TCP should be slower than UDP in a typical networking situation. scott On Mon, Jan 13, 2014 at 2:20 PM, Jonghyun Kim agitato...@gmail.com wrote: Hi list, I'm sending data between two computers, in every 10ms. For fast networking, TCP is better result? I don't know which is better. Most tutorials show example of OSC with UDP. Why? Thanks, Jong ___ 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
