Re: [PD] recursive controls problem
I took a stab at it. The main item here is the [set $1( message. That allows you to update the display/state of the slider without outputting a value. The [trigger a a] isn't needed for the patch to run correctly, but it makes it easier to see the connection that feeds back up the chain. -Jonathan On Friday, May 9, 2014 1:33 AM, plutek infinity plu...@infinity.net wrote: greetings! i'm sure this is a simple problem, but i can't seem to come up with the solution... i'm trying to control one numerical value in a few ways: 1. have a bang to set an initial value 2. have a slider for mouse control 3. use keyboard keys to increment and decrement the attached patch all works, except i ALSO want the slider position to pick up the current value, as changed by any of the other methods. the problem is, of course, that if i connect the expr result back up to the slider input, i get a loop with stack overflow errors. i'd be most grateful for any pointers you can offer... thanks much! cheers! .pltk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list multi-control_test_rev.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] more sprites!
Hi list, Here's another data structure sprite example: http://www.jonathanwilkes.net/sprite.webm I changed the object name and interface a little bit-- now sprites can have affine transformations. It's neat to use the transform method to see how few objects it takes to animate the sprite across the screen. Under the hood, the transform method should also be more efficient-- instead of vis'ing and unvis'ing the scalar, it just sends updated attribute to the image. Does anyone know if there's a standard sprite sheet format? Some sprite sheets divide up the sections into perfectly equal parts-- others look like they just spread them out arbitrarily through a png or gif. Atm I just take a directory as an arg and slurp up an image sequence. (And use imagemagick to split up the sprite sheet.) Best, Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
On 04/29/2014 10:44 PM, Jaime E Oliver wrote: I guess one of the nicest things about what you're showing is to do manipulations ala PWGL or open music. I'm interested in being able to make arbitrarily complex and long scores, and be able to export these as lilypond scores that can be edited and printed for someone else to play… I see. In that case I suppose you want to try to provide as much score-related data as you can for the converter to minimize your editing work. -Jonathan best, J On Apr 29, 2014, at 6:54 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/29/2014 05:28 PM, Jaime E Oliver wrote: Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… As far as notation inside Pd patches-- just the demo. But I do remember Ed saying he'd initially investigated using data structures for his project. If someone wants to build some higher level tools utilizing these new features of data structure, I'm happy to fix bugs and make any improvements that would be necessary. But higher level tools are tricky-- their design depends on what you want to do with the notation. As far as the data structures, in the next release I think I'll have the basic API the way I want it. At some point I'd like to investigate drawing xlets on scalars that forward messages to the parent [struct]-- that would hide the complexity of [pointer] and friends in most cases. Finally, I'd like to find a straightforward way to load canvases with [struct] definitions as libraries. At that point people will be able to build GUI objects directly in Pd. -Jonathan best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ 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] Music notation in pure data
On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Music notation in pure data
On 04/29/2014 05:28 PM, Jaime E Oliver wrote: Hi Jonathan, This is excellent work! I wonder in what direction are you taking this… As far as notation inside Pd patches-- just the demo. But I do remember Ed saying he'd initially investigated using data structures for his project. If someone wants to build some higher level tools utilizing these new features of data structure, I'm happy to fix bugs and make any improvements that would be necessary. But higher level tools are tricky-- their design depends on what you want to do with the notation. As far as the data structures, in the next release I think I'll have the basic API the way I want it. At some point I'd like to investigate drawing xlets on scalars that forward messages to the parent [struct]-- that would hide the complexity of [pointer] and friends in most cases. Finally, I'd like to find a straightforward way to load canvases with [struct] definitions as libraries. At that point people will be able to build GUI objects directly in Pd. -Jonathan best, J On Apr 29, 2014, at 1:20 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/28/2014 11:21 PM, Max wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014? 04? 29? 09:07, Jonathan Wilkes wrote: I think somebody had one using Gem and dynamic patching. that someone is Ed Kelly http://www.uni-weimar.de/medien/wiki/PDCON:Conference/Gemnotes:_A_Realtime_music_notation_system_for_pure_data Thanks. Here's a demo of a simple Lilypond score imported into Pd-l2ork: https://jwilkes.nfshost.com/notes.webm Benefits of data structures: * no dynamic patching needed * can display the music on a normal canvas * 2d API Drawback: * if you create a new scalar, the drawing instructions have to be sent to the gui. (Even worse, ds-arrays have to redraw the entire array atm.) But one could probably just instantiate a bunch of scalars and vis them as needed. -Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNfGsEACgkQ3EB7kzgMM6KDSwCbBRP53mn0kDf5UAy6sm9iU487 xMQAnjtBN571+jVjRLSp0fN1rubo/a4G =kUcj -END PGP SIGNATURE- ___ 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] Music notation in pure data
I think somebody had one using Gem and dynamic patching. I've got a demo using svg-style drawing instructions in Pd-l2ork. I'm almost finished working on nested svg groups-- at that point one should be able to output a page of Lilypond notation to svg and write an importer to convert to a Pd patch. -Jonathan On Monday, April 28, 2014 5:36 PM, Pagano, Patrick p...@digitalworlds.ufl.edu wrote: Is there a working music notator in PD? pp Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2070 ___ 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] make first inlet a proxy inlet
Let's say I have foo_class that creates object [foo] and bar_class which creates object [bar]. I want the inlet of both to forward incoming messages to an object of type blah_class which serves as a proxy inlet. (The struct of foo and bar would store a pointer to it and control creation and freeing of it.) Is there a way to specify this inside foo_new and bar_new, or is the easiest way to just use a class_addanything and forward messages that way? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] make first inlet a proxy inlet
I think I answered my own question. It looks like I can use CLASS_NOINLET, then create an inlet explicitly inside the *_new function for my classes. On Monday, April 21, 2014 4:49 PM, Jonathan Wilkes jancs...@yahoo.com wrote: Let's say I have foo_class that creates object [foo] and bar_class which creates object [bar]. I want the inlet of both to forward incoming messages to an object of type blah_class which serves as a proxy inlet. (The struct of foo and bar would store a pointer to it and control creation and freeing of it.) Is there a way to specify this inside foo_new and bar_new, or is the easiest way to just use a class_addanything and forward messages that way? -Jonathan___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Error: Stack stack
On 04/17/2014 03:49 AM, IOhannes m zmölnig wrote: On 04/16/2014 06:39 PM, Jonathan Wilkes wrote: you can locate many errors (though not all), for he tech savy: you can locate all error messages that use pd_error() or the not-so-new-but-still-newish logpost() to emit a message. by ctrl-clicking on the error-message in the Pd-console, When was that added, afar, 0.43 and where is it documented? src/CHANGELOG.txt? Nope. then there is [1], which is release announcement of Pd-extended but really lists a lot of features also found in Pd-vanilla. and every now and then it is mentioned on the list :-) Discoverability trick: if the word error: is a hyperlink, most users will know that they can interact with that error message. Since clicking a hyperlink is standard behavior in a modern UI, there wouldn't be a (pressing) need to document the behavior. In addition, a blue, underlined hyperlink fits perfectly with Pd's 1990s motif aesthetic. -Jonathan gfamse IOhannes [1] http://lists.puredata.info/pipermail/pd-list/2013-01/100666.html ___ 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: Stack stack
On 04/16/2014 11:16 AM, IOhannes m zmölnig wrote: On 04/16/2014 02:33 PM, Cyrille Henry wrote: the 1st thing to do in order to correct the problem is to locate it. +1. you can locate many errors (though not all), by ctrl-clicking on the error-message in the Pd-console, When was that added, and where is it documented? -Jonathan which should highlight the object that sent out the error-message. in the case of a stack-overflow this will be any one of the objects in the loop, but at least it gives you a starting point. gfrdsa IOhannes ___ 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] Keeping Number box's
On 04/14/2014 02:03 PM, Phil Stone wrote: Or use the Number2 number box, and set its init attribute in properties. It will then init itself with the last value that was in the box at the time the parent patch was saved. I try to avoid the iemgui init method because it isn't represented in the Pd diagram. I'd rather do this: [loadbang] [42( | [numbox] Then you can see if you made a mistake. For example, I forgot to connect [loadbang] to [42(. I can quickly scan all other places where I use [loadbang] to see if I made a similar error. But if you use the init method, you must right-click and choose Properties on every single numbox to do error checking. The time wasted isn't worth whatever it is you think you save by using init. Digression-- consider a Properties dialog with the following button: [don't fire nukes] Do you press it or not? -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] keeping Pd DSP alive
On 04/12/2014 04:27 PM, Chris Clepper wrote: Hi list I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely. I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it? Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies? In Pd-l2ork: [dsp-status( | [pdinfo] -Jonathan 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] keeping Pd DSP alive
There isn't a way to poll the DSP state in Pd Vanilla. -Jonathan On Saturday, April 12, 2014 8:47 PM, Chris Clepper cgclep...@gmail.com wrote: [pdinfo] is not part of vanilla. I can't (nor want to) use extended for this project. On Saturday, April 12, 2014, Jonathan Wilkes jancs...@yahoo.com wrote: On 04/12/2014 04:27 PM, Chris Clepper wrote: Hi list I'm wondering if there are any recommended ways to ensure DSP keeps running for long periods like permanent installations. I get 'audio I/O stuck' popping up every few days, which is not bad, but ideally audio should stay running indefinitely. I can send a [metro 1000] to [;pd DSP 1( to keep audio going, but is there any long term issue with doing that? Will it reliably restart audio after Pd closes it? Also, the internal message [;pd audiostate( only returns data to the console. Perhaps there is a way to poll Pd for the internal DSP state and restart it if it dies? In Pd-l2ork: [dsp-status( | [pdinfo] -Jonathan 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
[PD] Pd-l2ork release
There's a new Pd-l2ork release: http://l2ork.music.vt.edu/main/?page_id=56 Here's my vague recollection of what's changed: * New preferences dialog that includes GUI settings, audio, and MIDI settings * GUI presets (canvas bg, xlets, Pd window, search window, etc.) * New Put menu array dialog with canvas and array properties in the same dialog * Color choices for array trace * Bar-graph array style * Ability to create scalars inside an object box * New [draw] drawing command for scalars: adds svg shapes rect, circle, ellipse, line, polyline, polygon, and path. (No text yet) * Affine transformations, opacity, stroke, etc. messages for new draw commands * New tutorials and demos for [draw] object * New image and sprite draw commands (alpha) * Improved search-plugin There are a lot more changes that Ivica made-- I'll let him comment on those. Best, Jonathan___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Using GEM
Do you mean something like the attached abstraction? It turns your patches in a particular directory into a slideshow. It uses an object called [canvasinfo] which is only available in Pd-l2ork. If you don't use Pd-l2ork you can replace it with [iemguts/canvasname] (and remove the message box above it), but unfortunately [canvasname] in the last release of pd-extended had a bug that causes it not to work correctly in this case. -Jonathan On Tuesday, April 8, 2014 10:44 AM, Jack j...@rybn.org wrote: Le 08/04/2014 16:20, kate sweeney a écrit : Hello, I am currently doing my final year tech project in University. I am creating a graphic design + music project using GEM in Pure Data. I was wondering, is there a way to trigger certain patches, one after the other? For example, one patch creates moving particles, and the next creates 3d spheres. Is there a way to trigger these one after the other, using a bang etc? Thank you. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Hello, If you have you scenes (moving particles, 3d spheres, etc.) in the same patch. The simplest is to send 0 or 1 to [gemhead] to render a scene. One [gemhead] per scene. With this method, you can put each scene in a subpatch ([pd moving_particles], [pd 3d_spheres], etc.) and have a [receive ...] arriving on the [gemhead]. Then, somewhere in your main patch, you put a radio button and test the value return to activate a scene with [send ...]. ++ Jack ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list nav.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-04-03 03:05, Alexandre Torres Porres wrote: [...] btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of [qlist] and locality - very simple and forces you to think about your object interfaces. I would also recommend only using global receive-symbols when you have to use them. That way: * your patches are more readable * no need to feed $0 to message boxes * when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language -Jonathan fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -END PGP SIGNATURE- ___ 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] [qlist] and locality
For example, if you have two help patches open and each has an array inside it named array1. One of the help patches will work, and the other won't. That's because Put menu arrays assume you only have one array by that name. Pd will use the first one it finds (probably the first one you create) and the duplicate will be ignored. In the case of arrays you'll get a warning, because you're not supposed to use the same name twice. But with the send/receive classes (as well as many other objects that use pd_bind) you can have many s/r pairs sharing the same name. So suppose you have [s loop] and [r loop] in a subpatch, and [s loop] and [r loop] in an unrelated subpatch. Are those s/r pairs supposed to communicate with each other? Or... Did the author forget he/she already used the name loop for the first s/r pair and doesn't actually want the other s/r pair to communicate with the first? If the answer to the second question is yes, then that's an example of a nameclash. Pd doesn't give you a way to tell the difference. Most programming languages have clear and sensible ways to avoid this. There's even a Pd external to do it-- I think it's called [sendlocal] and [receivelocal]-- but its author erroneously thought that $0 deprecates those objects. Pd gurus on the list can give you seemingly simple workarounds for these problems with scope and nameclashes, but as you the programmer accumulate them it gets more and more unwieldy. Worse, it makes it difficult to read patches, as you must spend time decoding someone else's idiosyncratic use of [makefilename] or whatever they are doing to get Pd to do what is concise, consistent and robust in nearly every other modern programming language. Finally-- and again-- these problems cannot be improved in Pd without breaking some backwards compatibility. Just take the related issue of namespaces with external libraries-- it's hard enough to design and test something robust like Python's namespacing. Now imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible, and that means as long as people imagine Pd Vanilla as the core Pd $0 hackery is the only way to simulate scoping. -Jonathan On Thursday, April 3, 2014 12:35 PM, Alexandre Torres Porres por...@gmail.com wrote: * when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language what's a nameclash? (maybe I haven't outgrown Pd yet) 2014-04-03 13:00 GMT-03:00 Jonathan Wilkes jancs...@yahoo.com: On 04/03/2014 04:00 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-04-03 03:05, Alexandre Torres Porres wrote: [...] btw: i would probably even recommend to use explicit *connections* (rather than send/receive pairs) for anything local. then you never have the problem of [qlist] and locality - very simple and forces you to think about your object interfaces. I would also recommend only using global receive-symbols when you have to use them. That way: * your patches are more readable * no need to feed $0 to message boxes * when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language -Jonathan fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPRULAAoJELZQGcR/ejb4NioP/0Kyyz4MA+Tqq8890uEHGj9Z FZHEo5z/idBj7Z+WmAHrEipkIW70pnVBB4bVzC8owgV66AQZBuEqXMeJcIpu3MXK ULvsvxcFcoY9YH7hbJAF+mlDFvbh1CXcVbvEChZ8y5rz0XekSMf+//qUfJSlKTWX GXjJzw8s42yfSpVJYBjEh6fBFzlk2foLRFPFXaR6Cbj+Y7aNEiW//+Vim3nOzleT 6azYe0leLabir72nnWIKGahnT2GXgWkgxu6L//nTgsBYOa1COUoKOh44wvBbMSoW lbLduDY5drxJbyISGoZdsuailriv1xMGIkiSwTw4WSwVWBj2kv5MgoHC09ugqtLe bVHrizcP09+VUz20y8IMnXrRRgj8AU8Z+9xzZIzf9PV3U15zSlRqwZSFIwMCuhYs CeRqxtDFVsB/PARQoCys/B4QDjAszBPE2VC1xKSelBMjyGbvPyZA7uq/R199zLCy WMp0uu0+Q6WKa/zIB+sphLlifnXjYYXJaCGZNOzign1EJLOnBvOY/4zgE3bHtx9r FIlSFSMo6BrYjOEJvh/MxF90TawI/aCQ/MbEea0+finxJi2jp2PnMom+QbCvjfBa zLh8hlNP0tLp21Jo1ydzu0/vYb9mEzMQtpEv9lqrde0INcEKL9TaswFGf5TXyM7h JeTnSBV0Th0CjQER9Gik =oC+u -END PGP SIGNATURE- ___ 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] [qlist] and locality
On 04/03/2014 04:14 PM, Roman Haefeli wrote: On Don, 2014-04-03 at 12:00 -0400, Jonathan Wilkes wrote: * when you run into nameclashes, you know your project has outgrown Pd and it's time to choose another language That is a pretty bold statement. It's meant as a shortcut to avoid wasting time. I never ever run into name clashes, no matter how big the project was/is. The no-name-clash dogma: * Do not use global s/r-symbols (simple) Except you have two points below which contradict this! But I suppose you meant to write that one shouldn't use global s/r-symbols except for the two special cases below. Even so, what you ignore is the entire learning curve that accompanies the dogma. The new user is presented with the perverse starting point that the simple, common case of global symbols should be used almost never and the cryptic, dollarsign-zero symbol names should be used almost always. Because the user must rely on cryptic dollarsign symbols for locality, patching is more error-prone, and patches are harder to read. Every message box is accompanied by the user's choice of extra patch cruft to feed $0 into it. Maybe it's [f $0], [list prepend $0], an abstraction, or something else. That yet one more little detail to check when things go wrong, and it's there because the user is forced to type something extra to get patch locality, which is most often what the user needs. So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages. -Jonathan * Use global s/r-symbols for singletons (i.e. one server, many clients) * Use global s/r-symbols in cases where the protocol is multinode-aware. (No matter how many instances of an abstraction using a global s/r- symbol are created, they will always be able to communicate with each other in the same way) 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] [qlist] and locality
On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote: thanks for explaining it all imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you? I don't know how difficult such a change is. I assume something in Pd's parser would need to be changed. I can't remember if the code responsible for parsing a msg box message even knows where the message got sent from-- seems ike it doesn't since I can't find last error on msg-box parsing errors (like an out-of-range dollarsign variable). What I'm saying is that even with a canvas $0 inside message boxes Pd's scope system is still way too clunky. You still don't get straightforward subpatch-locality, nor nested-abstraction locality. I think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and [preset_node] get the latter (though I don't think it does global scope). Both work perfectly fine with no $0 at all. The pedagogical benefit is enormous-- new users can get the scope they want without having to learn or think about what a dollarsign variable is, or how string concatenation works. In the case of [preset_hub], just creating the object sets the scope boundary almost certainly to what the user wants it to be. I like that. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On 04/03/2014 05:42 PM, Roman Haefeli wrote: On Don, 2014-04-03 at 17:33 -0400, Jonathan Wilkes wrote: So yes, it's rather extreme of me to advise users to just use global symbols and switch languages when they run into problems. But I think there's an assumption on this list that most users know enough about other programming languages to judge for themselves the level of expressiveness in Pd. I don't think that's true, and I think it's important to remind people just how clunky Pd is in these respects compared to other modern languages. Clunky or not, Pd is the language I feel the most expressive with. YMMV. Sorry, I'm not using the best terminology here. I'm talking about the practical expressivity of the language. For just one example-- let's say you wanted to make a polyphonic patch with 30 oscillators, and send them messages to set initial frequency and amplitude. Let's use Old-school Pd which doesn't have abstractions. You make a subpatch, get it the way you want it, copy it, then paste it 29 times. Now when you need to make changes to the subpatch, you need to delete the other 29, copy the one you changed and paste it 29 times. That sucks. Now let's look at New-school Pd which has abstractions. In this case you get your abstraction the way you want it, instantiate it on a canvas, copy it, and paste it 29 times. Now when you want to make a change to the abstraction, you click Save and Pd automatically pushes your changes to all instances of your abstraction. You don't have to copy/paste everything again. That's very simple, but it's one of the ways abstractions can make Pd more expressive. So you can express yourself by programming in either version of the language. But the New-school version makes it easier to do that. That may be clearer with the example of abstractions-- which you no doubt use all the time-- than with examples of scope that don't rely on $0. But that's why I refer to other modern languages which don't suffer from that roadblock. -Jonathan 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] [qlist] and locality
On 04/03/2014 06:33 PM, Alexandre Torres Porres wrote: Hi Jonathan, I like it too, and the pedagogical concern is what gets me the most. I find new users to be reluctant to the clunkiness. Had never heard of the Nova system, is it available somewhere? Seems it's not built on the core of Pd anyway, right? No, it was abandoned. I believe Tim develops something for Supercollider called Supernova which allows users to take advantage of parallelism when doing DSP. [preset_hub] is in Pd-l2ork. -Jonathan thanks 2014-04-03 19:03 GMT-03:00 Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com: On 04/03/2014 03:13 PM, Alexandre Torres Porres wrote: thanks for explaining it all imagine trying to design something like that which is also backwards compatible with the crude namespacing tools that already exist in Pd. It's not possible ok, here's where I'm a bit confuse. You're not saying it'd be impossible to make messages inherit the $0 value, are you? I don't know how difficult such a change is. I assume something in Pd's parser would need to be changed. I can't remember if the code responsible for parsing a msg box message even knows where the message got sent from-- seems ike it doesn't since I can't find last error on msg-box parsing errors (like an out-of-range dollarsign variable). What I'm saying is that even with a canvas $0 inside message boxes Pd's scope system is still way too clunky. You still don't get straightforward subpatch-locality, nor nested-abstraction locality. I think Tim Blechmann's Nova system did both, and Ivica's [preset_hub] and [preset_node] get the latter (though I don't think it does global scope). Both work perfectly fine with no $0 at all. The pedagogical benefit is enormous-- new users can get the scope they want without having to learn or think about what a dollarsign variable is, or how string concatenation works. In the case of [preset_hub], just creating the object sets the scope boundary almost certainly to what the user wants it to be. I like that. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On 04/03/2014 07:13 PM, Roman Haefeli wrote: [...] Thanks for your remarks. You probably caught me in the act of feeling comfortable in an actually not so comfortable situation. It's true that people get accustomed to the environment they grow up in. I've never challenged myself into thinking how things could be different as I found ways to cover my needs with the clunky locality of $0. Not yet fully seeing the impact, you convinced me that a more 'true' locality would probably make some things easier. And that is certainly not everything where Pd is clunky. I still find myself using dynamic patching for problems I don't know how to solve otherwise and that is not even an officially supported feature with a definitely clunky interface. Do you have any examples of such problems? I'd be curious to see... -Jonathan 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] [qlist] and locality
On 04/02/2014 03:08 AM, Roman Haefeli wrote: On Tue, 2014-04-01 at 17:20 -0300, Alexandre Torres Porres wrote: you might want to see the messages sent by [qlist] the same as messages in msgboxes, where you don't have $0-expansion either Bummer. anyway, this brings me to a different topic then. Why is there this lack of expansion in messages? Message boxes _do_ expand dollar arguments. I think I've raised this issue sometime ago. Sorry I don't remember what the problem was, but I'd like to ask again if it's really really hard to expand the functionality in messages, or if this could happen sometime soon in Pd. The difference is that dollar arguments in message boxes expand to the incoming message while dollar arguments in object boxes expand to the arguments given to the parent. $0 in object boxes is actually an argument given implicitly by Pd to the parent (every instance of a Pd file gets a separate one). I believe there won't be any compatibility issues by expanding this functionality. Old patches will still work and newer patches could be simpler, right? You're asking for inconsistency: You propose to have a mixture of dollar arguments in message boxes, namely you want $0 to expand to an argument of the parent and all other dollar arguments expand according to the incoming message. I think what the OP wants is some minimally-workable notion of scope wrt receive-symbols. Because $0 doesn't deliver this, the next best thing is an inconsistent $0 that gets closer to minimally-workable scope. It says something that so many people are willing to overlook the inconsistency to get behavior that doesn't cause them to pull their hair out. While I also don't see how your proposal would break compatibility, I think what I said above is the reasoning why things are how they are. Tim Blechmann already addressed scope and implemented a solution in Nova. There are certainly developers in the Pd community who could port that idea, or maybe even something better. But free software devs have limited time, and they're smart, so they know if a now prominent Supercollider dev can't get such a needed improvement into Pd then they probably have 1000 better ways to spend their time. -Jonathan While I don't have a strong opinion on the subject matter, I suspect it is not going to be changed soon (it was brought up a few times already, iirc). 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] Alternatives to arraycopy
I used some simple data mining techniques to infer the following: you didn't actually test those objects in a patch before writing your response. [ads based on this inference go here] -Jonathan On Monday, March 31, 2014 9:05 AM, Miller Puckette m...@ucsd.edu wrote: Just play it (tabplay~) into the other one (tabrecord~). You can do this at many times 'normal' speed if you want by putting it in a subpatch with a high sample rate. cheers Miller On Mon, Mar 31, 2014 at 08:58:22AM -0400, Johann Diedrick wrote: Hi Pd list- I have a question about the object arraycopy. It works great, but I'm copying an array with 1323 points (5 minutes of audio at 44,100 hz) and it seems very slow. In particular, my patch seems to lock up for about 2-3 seconds when making the copy. The audio stops for those 2 seconds, and the UI seems to lock up. While this isn't a huge game changer for my purposes, I wish there was an alternative for this. Is there a better solution for making a copy on the fly for an array this big that is faster, doesn't lock up the patch or kill the audio for that time period? Maybe there is a threaded solution? I'd love to hear any thoughts on this! Thanks so much, -Johann ___ 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] Pd-L2Ork [ii]
On 03/31/2014 12:25 PM, IOhannes m zmölnig wrote: On 03/31/2014 05:09 PM, Jonathan Wilkes wrote: a) click [loadbang] with the mouse to output a bang. (This is how Max/MSP solves this problem, too.) b) select all the objects to which you'd like to connect, then draw a connection from [bng] to one of them. In Pd-l2ork this will make a connection from the outlet to all of the selected objects. c) replace [loadbang] with [t b], then create a [bng] and a new [loadbang] and connect both to that [t b]. Yeah, I forgot about that one. It's a nice trick of recycling a wire which generalizes to other situations, too. -Jonathan this is still a lot more work that a), but a lot less than b) if you don't have Pd-l2ork's patching features though it might be more readable. fgmdsar IOhannes ___ 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] comments as one long symbol
That way we could implement a simple translation system. When Pd loads a patch it looks for a translation file in the local language that share the same base file name as the patch. If there isn't a translation file then a comment would load as is. If there is a translation file for the user's language then Pd searches the translation file for the comment and loads up the corresponding translated comment. So why do comments as one long symbol help? Because then a search is as simple looping through an array of atoms and doing: if (gensym(buf) == gensym(translation_file_buf)) Fast and simple. And you just need an extra entry in the ce_env struct to hold the name of the translation file for the user's locale. I still don't know how gettext works, but I'm guessing we could set it up to pull out comments from a Pd file, then use that to generate the template for the help patch translations. Comments? Attacks? Beers? -Jonathan___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd source code style
In the changes.txt it says that indentation is four spaces? Does that mean that a click of the tab key is supposed to generate four consecutive spaces? I don't see any tab characters in the source (unless I'm searching them wrong.) Thanks, Jonathan___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd source code style
Great. Thanks, Jonathan On Saturday, March 22, 2014 2:37 PM, Miller Puckette m...@ucsd.edu wrote: There aren't any tabs (so that it doesn't matter how you have set your tab spacing to look at the code). The code uses 4-space indentation. (That shouldn't be affected by tab spacing). cheers Miller On Sat, Mar 22, 2014 at 11:08:50AM -0700, Jonathan Wilkes wrote: In the changes.txt it says that indentation is four spaces? Does that mean that a click of the tab key is supposed to generate four consecutive spaces? I don't see any tab characters in the source (unless I'm searching them wrong.) Thanks, 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] log function in slider
No, the code I ported is from vslider_set and vslider_draw_update (might be different in Vanilla). In vslider_bang, math is done to output the proper value. Without looking at the code I would have guessed vslider_bang simply outputs a stored value like [float] does. Then just do math to set the slider position or calculate a new stored value from mouse input. -Jonathan On Monday, March 17, 2014 1:21 AM, Alexandre Torres Porres por...@gmail.com wrote: Hi Roman. This is turning out trickier than I thought. A friend explained the code to me and got to the following equation, with min/max values as 0.01 and 1 respectively. [expr 0.01 * exp((log(1 / 0.01) / 0.01) * $f1 * 0.01)] For what I've checked, it seems to behave like your patch. But it doesn't do the trick I'm looking for yet. I sent a patch earlier, and I'm sending it back again. The goal is to connect a linear slider to an [expr] (with this so called log function) and then to another linear slider. The idea then is that this second slider behaves as one that was set as being log. In the patch attached I was able to emulate it poorly with [pow 0.25], but that was before reaching the list. See that if I use this expr function from the code or your patch it presents quite a different behavior. maybe it is some sort of inversion of this equation, not sure. Apparently this code converts the log function values to linear and I'm hoping to get the exact opposite. Got it? Thanks for looking into this 2014-03-12 4:38 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Don, 2014-03-06 at 21:37 -0300, Alexandre Torres Porres wrote: hi folks, out of curiosity, what's the exact log function used in the slider? I'd like to emulate it. I am not sure, if this is what you want. It converts the incoming linear range between 0 and 1 to a logarithmic range specified by $1 and $2, respectively by the second and third inlet. They behave like the lower and upper bound specified in the [vslider]/[hslider] classes. https://raw.github.com/reduzent/netpd2-patches/master/abs/rh_scalelog.pd 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] log function in slider
AFAICT vslider is saving something like a slider position, and your expression above (along with the code I posted) is for getting back the original value from it. If you send it something between 0.01 and 1 you'll get a curve that's inverted from the one you're after. If you send it a slider position-- something like another [expr] based on the code inside vslider_set-- you'll get back (roughly) the same value you input. But I'm still stuck on why vslider_bang is doing any math at all. Why should it be more complex than if bang then output stored value? (Setting aside sending to receive symbols for the moment.) -Jonathan On Monday, March 17, 2014 1:21 AM, Alexandre Torres Porres por...@gmail.com wrote: Hi Roman. This is turning out trickier than I thought. A friend explained the code to me and got to the following equation, with min/max values as 0.01 and 1 respectively. [expr 0.01 * exp((log(1 / 0.01) / 0.01) * $f1 * 0.01)] For what I've checked, it seems to behave like your patch. But it doesn't do the trick I'm looking for yet. I sent a patch earlier, and I'm sending it back again. The goal is to connect a linear slider to an [expr] (with this so called log function) and then to another linear slider. The idea then is that this second slider behaves as one that was set as being log. In the patch attached I was able to emulate it poorly with [pow 0.25], but that was before reaching the list. See that if I use this expr function from the code or your patch it presents quite a different behavior. maybe it is some sort of inversion of this equation, not sure. Apparently this code converts the log function values to linear and I'm hoping to get the exact opposite. Got it? Thanks for looking into this 2014-03-12 4:38 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Don, 2014-03-06 at 21:37 -0300, Alexandre Torres Porres wrote: hi folks, out of curiosity, what's the exact log function used in the slider? I'd like to emulate it. I am not sure, if this is what you want. It converts the incoming linear range between 0 and 1 to a logarithmic range specified by $1 and $2, respectively by the second and third inlet. They behave like the lower and upper bound specified in the [vslider]/[hslider] classes. https://raw.github.com/reduzent/netpd2-patches/master/abs/rh_scalelog.pd 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] log function in slider
On 03/17/2014 04:34 PM, Roman Haefeli wrote: On Mon, 2014-03-17 at 02:21 -0300, Alexandre Torres Porres wrote: Hi Roman. This is turning out trickier than I thought. I think I understand now what you are trying to achieve (sorry, took me a long time). But I don't really have a clue how to do it. The abstraction I posted emulates the output of a logarithmic slider, but you're looking for the function to feed a linear slider so that it behaves as if it would be a logarithmic slider, right? I'm interested to see, if someone comes up with a solution... This is from Pd-l2ork, so the codebase might be slightly different. Also, notice I've got hard-coded slider height = 128 in the algo. Still don't understand why math is done in vslider_bang. -Jonathan Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas -9 19 513 614 10; #X obj 16 319 cnv 15 202 227 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 65 57 cnv 15 351 255 empty empty empty 20 12 0 14 -233017 -66577 0; #X floatatom 148 27 5 0 0 0 f - -, f 5; #X obj 217 162 log; #X obj 217 120 f 1; #X obj 217 141 / 0.01; #X obj 217 183 /; #X obj 276 131 f 128; #X obj 276 152 - 1; #X text 331 139 x_k; #X obj 148 142 / 0.01; #X obj 148 163 log; #X obj 148 230 /; #X obj 148 67 t a b b; #X obj 148 251 * 100; #X obj 148 272 + 0.4; #X obj 148 293 int; #X text 190 295 - x_xval; #X obj 148 374 t b a; #X obj 148 395 f 2; #X obj 148 416 + 127; #X obj 148 437 -; #X text 183 435 - r; #X obj 148 324 + 50; #X obj 148 345 / 100; #X obj 235 493 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X msg 148 459 128 \$1; #X obj 148 480 -; #X obj 288 493 vsl 15 128 0.01 1 1 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X text 68 58 vslider_set; #X text 21 326 vslider_draw_update; #X text 115 581 linear slider -; #X text 315 581 - logarithmic slider; #X connect 2 0 13 0; #X connect 2 0 28 0; #X connect 3 0 6 0; #X connect 4 0 5 0; #X connect 5 0 3 0; #X connect 6 0 12 1; #X connect 7 0 8 0; #X connect 8 0 6 1; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 12 0 14 0; #X connect 13 0 10 0; #X connect 13 1 4 0; #X connect 13 2 7 0; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 23 0; #X connect 18 0 19 0; #X connect 18 1 21 1; #X connect 19 0 20 0; #X connect 20 0 21 0; #X connect 21 0 26 0; #X connect 23 0 24 0; #X connect 24 0 18 0; #X connect 26 0 27 0; #X connect 27 0 25 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] udoo board sound issues
On 03/16/2014 05:33 AM, Simon Iten wrote: [...] Any digital instrument also has latencies. Basically it is a matter of playing the instrument you are using. How are you measuring the latency? -Jonathan 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] using pd live (sans computer/laptop/raspberry pi)
On 03/14/2014 03:44 PM, Dan Wilcox wrote: Without a computer, no. Without a desktop or laptop computer, yes. Well, maybe we could design and manufacture an enormous ASIC that runs libpd. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Data structures and click event
On 03/07/2014 06:55 PM, Miller Puckette wrote: I'll have to have a look and see what the ideas are... I don't know anything yet. Well there's the important stuff: https://jwilkes.nfshost.com/mm.webm And then the less important stuff, like being able to patch 15 out of the 28 demos shown here: http://raphaeljs.com/ Essentially everything except the ones with gradients and text, but those features can be added later. It's generally not as high level as Raphael-- for example I ported the Raphael code to subpatches for the easing demo, and I'm just using [line] to do the animation. However, it would not be too hard on the Pd side to add an animate method. In fact that'd be quite efficient as you'd only be sending a single message over the socket and letting the GUI take care of the details. Also, I'm instantiating scalars inside object boxes. Since the user can send messages to update shape attributes straight to the parent draw command, this means he/she can do an end-run around pointers for prototyping. So essentially you have the ability to dynamically change visual attributes on the class level (i.e., the parentwidgetbehavior) and on the object level (for the specific scalar, as you can currently). There are still lots of details to get right, like handling groups properly, but the basic stuff is there. -Jonathan Anyhow I think there are a couple of things that are higher priority: getting editing to be more user-friendly, and getting the IEM GUIs to behave better. And I'm afraid I can only write code at a fraction of the speed others can - so PD vanilla will always seem years behind everything else. cheers Miller On Sat, Mar 08, 2014 at 12:45:33AM +0100, João Pais wrote: On 03/05/2014 05:24 AM, Pierre Massat wrote: Dear list, First of all i'd like to say that i'm very impressed by the potential of data structures in Pd. I've always kind of ignored this feature and it's a pity because it's really worth diving into it.That being said I think that help and example patches are far from sufficient for beginners, and if it wasn't for Chris McCormick's s-abstractions I would have been able to really figure out how to use them (stuff like how to make an entire polygon draggable, how to use GOP with proper scaling, etc.). It's not just the documentation, it's the interface. Having to walk linked-lists of graphically unlinked objects is bad. Having to use boilerplate to find the head of a glist just to create a scalar is bad. I think Pd-l2ork is getting close to a release with my new data structure stuff in it. It's a first step at addressing some of these issues. and any prospects of that stuff making it into vanilla or pd-ext, for the non-unix users out there? ___ 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] Tcl invalid command with [TuioClient] and Pd-extended 0.43.4
On 03/11/2014 12:29 PM, Jack wrote:
Hello,
I need help to understand this problem (see below) and solve it.
It seems to work fine with Pd-Ext 0.42.5 (but not with Pd-Ext 0.43.4).
That leads me to believe it has something to do with the GUI rewrite,
which happened between 0.42 and 0.43.
Here's the relevant code-- line 90 in source/TUIO/TuioClient.cpp
if (socket!=NULL) {
if (!socket-IsBound()) {
delete socket;
socket = NULL;
} else std::cout listening to TUIO messages on UDP
port port std::endl;
}
***
Somehow std::cout must be printing to the console in 0.42 and sending to
the gui (i.e., tcl) in 0.43.
If you send a GUI message to tcl it interprets the first word as a
command. That's why you get the error below.
I don't know enough about c++ to give you a fix, but I'm sure someone
else on the list does.
Btw the relevant code is here:
http://sourceforge.net/projects/reactivision/files/TUIO%201.0/TUIO-Clients%201.4/TUIO_PureData-1.4.zip/download?use_mirror=tenetdownload=
Then unzip the nested source.zip.
-Jonathan
Thanx.
++
Jack
Le 16/04/2013 12:08, Marco Donnarumma a écrit :
I can confirm, the GUI doesn't show up at all on my machine too.
Linux Lucid 10.04 pd-ext 0.43.4
--
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
Embodied Audio-Visual Interaction Research Team.
Department of Computing, Goldsmiths University of London
~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com
Director: http://www.liveperformersmeeting.net
Subject: [PD] Tcl invalid command with [TuioClient] and Pd-extended
0.43.4
To: PD List pd-list@iem.at mailto:pd-list@iem.at
Message-ID: 516c5543.2070...@rybn.org
mailto:516c5543.2070...@rybn.org
Content-Type: text/plain; charset=iso-8859-1
Hello,
I am working on a patch in which i use [TuioClient] with
Pd-extended 0.43.4
When i open this patch, i get in the Pd console :
Invalid command name 'listening'
while executing
listening to TUIO messages on UDP port
(uplevel body line 1)
invoked from within
uplevel #0 $cmds_from_pd
Then, very often, there is no GUI and i can't use the patch.
How I can make this patch work (attached) all the time for an
installation (with TuioClient.pd_darwin from tuio.org
http://tuio.org) ?
My configuration :
MacMini with MacOSX.7.5
Pd-extended 0.43.4
Thanx.
++
Jack
___
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] log function in slider
Wow, never mind-- it's a veritable Rube Goldberg machine of code to get from an incoming float to an outgoing one in g_vslider.c. There's even more math to draw the tick and I can't figure out how it works at the moment. I also love how tempting log is for a volume control, but then it silently changes a minimum of 0 to max / 100, so you get a runtime error where you can't turn the volume down all the way. Then when you figure out what it did you have to add an object to subtract that last little bit, at which point you might as well have used [rms] or coded your own algorithm. -Jonathan On Tuesday, March 11, 2014 8:08 PM, Alexandre Torres Porres por...@gmail.com wrote: Thanks Jonathan. Unfortunately, my C expertise is kinda poor and I'm still lost. I see it's got something to do with [exp] but haven't got my head around the function needed to emulate it. I'm making extensive documentation about Pd, so I'd like to write about it. I find it worth noting. In the patch I'm sending, which was my attempt to get this right before reaching the list, I was able to emulate a bit reasonably with [expr pow($f1, 0.25)]. Cheers 2014-03-06 21:56 GMT-03:00 Jonathan Wilkes jancs...@yahoo.com: From g_vslider.c: if(x-x_lin0_log1) out = x-x_min*exp(x-x_k*(double)(x-x_val)*0.01); Where x-x_k is: log(x-x_max/x-x_min)/(double)(x-x_gui.x_h - 1); And x-x_gui.x_h is the height of the slider -Jonathan On Thursday, March 6, 2014 7:37 PM, Alexandre Torres Porres por...@gmail.com wrote: hi folks, out of curiosity, what's the exact log function used in the slider? I'd like to emulate it. cheers ___ 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] 100k lines of code (was libpd separating gui from core)
In Pd-l2ork: [dir( | [canvasinfo] And for dir of Pd binary: [dir( | [pdinfo] And don't take IOhannes' bait. He's implying that Pd Vanilla is a community project-- that if _we_ coded up a currency converter, or some much more pressing functionality, Miller would accept that code. That is clearly not the case. Additionally, IOhannes also knows that Miller wants the [initbang] functionality in the form of a backwards-compatible [loadbang] which takes arguments. Why does he argue with you about priority instead of coding that up? If Pd Vanilla were a community project I'd say, show me the code. Instead, I think he's being prudent and knows from experience that Miller doesn't delegate responsibility for new features but instead codes them up himself, when he feels like it. (And evidently with very little priority as the [initbang] functionality has been requested for a very long time and data structure list fields not at all.) And that's fine for a personal project like Pd Vanilla or Nyquist. Those authors are kind enough to release their software under a permissive license and have never asked for a community of helpers. It just leads to unnecessary frustration when others imply these things are upstream from other projects and pretend that there's a workable development process centered around them. -Jonathan On Monday, March 10, 2014 11:54 AM, Dan Wilcox danomat...@gmail.com wrote: It doesn't have to be a direct include, could be done with any sort of mechanism. I do agree that [getdir] is one of the few essential externals I still need after I ported my patch lib to vanilla ... that and [stripdir] / [splitfilename] but the latter will be possible with the new [list tosymbol] / [list fromsymbol] mechanism. On Mar 10, 2014, at 11:10 AM, i go bananas hard@gmail.com wrote: I'd also like to see [getdir] made vanilla. There is literally no way to do that without the external. 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] 100k lines of code (was libpd separating gui from core)
On 03/10/2014 12:56 PM, IOhannes m zmölnig wrote: On 03/10/2014 05:38 PM, Jonathan Wilkes wrote: Additionally, IOhannes also knows that Miller wants the [initbang] functionality in the form of a backwards-compatible [loadbang] which takes arguments. [...] thanks for the insights. i didn't know that i knew *that*. i would therefore be interested how i could have known it. Sorry, I assumed you read the relevant publicly available thread that has messages you authored weaving through it: http://article.gmane.org/gmane.comp.multimedia.puredata.devel/8611 That's from 2010. For a patch you submitted in 2006. We're currently in 2014. That such a feature would take nearly a decade to get into the professed core (and still isn't included, in any form) is a symptom of an unhealthy development process. An unhealthy development process keeps potential developers from participating and improving the software, which is a vicious cycle. -Jonathan vcmr IOhannes ___ 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] change array graph size
On 03/09/2014 08:15 PM, João Pais wrote: Hello, I wanted to change the graph canvas of an array, but I can't find the way of doing it. If I have an array called array1, to where should I send a coords message? Does it work like a normal GOP? The graph is named graph$n, where $n is incremented for each graph that exists in the Pd instance. So you'd send to pd-graph$n in order to do that. In Pd-l2ork you just move the mouse down to the bottom-right corner of the Put menu array, and you get a cursor that lets you click-drag the graph to change its size. -Jonathan Thanks, jmmmp ___ 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] Data structures and click event
On 03/08/2014 12:46 PM, Dan Wilcox wrote: On Mar 8, 2014, at 5:59 AM, pd-list-requ...@iem.at mailto:pd-list-requ...@iem.at wrote: No. It requires a toolkit that has modern 2d features like affine transformations and opacity, etc. Pd-l2ork leverages Tkpath, a tcl/tk library. Other modern toolkits like Qt have their own 2d interfaces with the same features and could be used, but tcl/tk on its own does not. for the non-unix users out there? For OSX, one of the tcl/tk libraries-- Tkpath needs to be ported from Carbon to Cocoa. I have this about halfway done. I finally found the old QuickTime Carbon headers so I could port the old school font creation to CoreText. All of the old Quick Draw stuff is no longer on the Apple Developer docs, so it was a bit confusing at first. It will take a little while though since I dip into it now and then among everything else. Hey that's great! I can probably help once you get that part ready. One issue will be to making sure everything builds using a newer version of tcl/tk than what Pd-extended currently ships with. It might be good just to go ahead and try 8.6 since it has some new tk::mac goodies. I haven't investigated a Windows port yet but it's probably mostly a matter of setting up the proper compile environment more than anything else. Granted one would probably need to tweak pd.tk and L2ork's build script, but getting set up in Windows seems to be where most of the work is. (At least in my experience so far.) It shouldn't require too much beyond the current steps to build vanilla or extended on Windows: a mingw + msys enviornent. Tkpath uses an autoconf build system so it should be fine on Windows as long as you point it to the tcl/tk headers. The issue with OSX is that it simple hasn't been updated in a while but I imagine it's fine on Windows since MS moves very very slowly as far as moving to new APIs is concerned. There are a few other tk libs Pd-l2ork uses. I'm also assuming Tkpath doesn't have any crashers in Windows-- I haven't tried it yet. -Jonathan 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] Data structures and click event
On 03/07/2014 06:45 PM, João Pais wrote: On 03/05/2014 05:24 AM, Pierre Massat wrote: Dear list, First of all i'd like to say that i'm very impressed by the potential of data structures in Pd. I've always kind of ignored this feature and it's a pity because it's really worth diving into it. That being said I think that help and example patches are far from sufficient for beginners, and if it wasn't for Chris McCormick's s-abstractions I would have been able to really figure out how to use them (stuff like how to make an entire polygon draggable, how to use GOP with proper scaling, etc.). It's not just the documentation, it's the interface. Having to walk linked-lists of graphically unlinked objects is bad. Having to use boilerplate to find the head of a glist just to create a scalar is bad. I think Pd-l2ork is getting close to a release with my new data structure stuff in it. It's a first step at addressing some of these issues. and any prospects of that stuff making it into vanilla or pd-ext, No. It requires a toolkit that has modern 2d features like affine transformations and opacity, etc. Pd-l2ork leverages Tkpath, a tcl/tk library. Other modern toolkits like Qt have their own 2d interfaces with the same features and could be used, but tcl/tk on its own does not. for the non-unix users out there? For OSX, one of the tcl/tk libraries-- Tkpath needs to be ported from Carbon to Cocoa. I haven't investigated a Windows port yet but it's probably mostly a matter of setting up the proper compile environment more than anything else. Granted one would probably need to tweak pd.tk and L2ork's build script, but getting set up in Windows seems to be where most of the work is. (At least in my experience so far.) -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] arrays in GOP abstraction, show up in parent patch
Shows up in Pd Vanilla. Doesn't show up in Pd-l2ork (latest build from git). -Jonathan On Thursday, March 6, 2014 10:32 AM, Jaime E Oliver jaime.oliv...@gmail.com wrote: Hi all, The title says it all, I have some arrays in abstractions and any new value input into the array is also graphed in the parent patch. This happens in OS X 10.8.5 w/latest pd. It does not happen with 0.42-5. testing patch attached. best, J ___ 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] log function in slider
From g_vslider.c: if(x-x_lin0_log1) out = x-x_min*exp(x-x_k*(double)(x-x_val)*0.01); Where x-x_k is: log(x-x_max/x-x_min)/(double)(x-x_gui.x_h - 1); And x-x_gui.x_h is the height of the slider -Jonathan On Thursday, March 6, 2014 7:37 PM, Alexandre Torres Porres por...@gmail.com wrote: hi folks, out of curiosity, what's the exact log function used in the slider? I'd like to emulate it. cheers ___ 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] Data structures and click event
On 03/05/2014 05:24 AM, Pierre Massat wrote: Dear list, First of all i'd like to say that i'm very impressed by the potential of data structures in Pd. I've always kind of ignored this feature and it's a pity because it's really worth diving into it. That being said I think that help and example patches are far from sufficient for beginners, and if it wasn't for Chris McCormick's s-abstractions I would have been able to really figure out how to use them (stuff like how to make an entire polygon draggable, how to use GOP with proper scaling, etc.). It's not just the documentation, it's the interface. Having to walk linked-lists of graphically unlinked objects is bad. Having to use boilerplate to find the head of a glist just to create a scalar is bad. I think Pd-l2ork is getting close to a release with my new data structure stuff in it. It's a first step at addressing some of these issues. -Jonathan I m now stuck with a question. How can I identify the element which was just clicked ? I know that [struc] outputs the events, like click, selection and change, but I thought I could identify individual elements by their pointer id. It turns out that I get the same pointer for every element, although I created them sequentially (using [append]). (I guess something must be escaping me about pointers... I've noticed that within the same template, I get different pointers for elements on different y-levels, but the same pointer for all the element on the same y-level regardless of their x.) Cheers, Pierre ___ 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 as sound editor (issue with scrolling a table) ??
On 03/05/2014 04:36 AM, i go bananas wrote: Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element. why do the iem tab objects work so much better then? I haven't looked at the code, but I'd imagine those externals do some array-wide operation then trigger a single redraw of the entire array. For a 100-element array that'd be 100x faster. But if you want the GUI to look modern you want the chunk of samples you're displacing to redraw ASAP. For that Pd (Vanilla) still needs to continually delete and redraw the array as you click-drag the selection. So it's better than the worst of all possible worlds-- using [tabwrite]-- but still extremely inefficient (not to mention it doesn't scale). To be fair, it's unclear how to do this right even with a clean separation of GUI/core. It's unclear what clean means, and it's unclear what this is. To be specific: it's really hard to predict what purpose the user will find for the realtime audio engine when the GUI is also a programming language. For example, you can get all kinds of speedups in a DAW by waiting for the user to release the mouse button when displacing a selection. But if you did that by default for Put menu arrays you'd ruin several of Miller's tutorials, where an immediate connection between visual array change and audio change is vital if inefficient. -Jonathan maelstorm said that it was incredibly slow using an [until] based counter, but worked smoothly with the iem objects. This was for EXACTLY the same gui, so i'm not really sure if it's a gui redraw issue. Then again, he also said that the iem tabs objects seem to process tables in chunks...so maybe the gui is also only redrawn in those chunk sizes? that would make sense i guess. On Wed, Mar 5, 2014 at 10:35 AM, Billy Stiltner billy.stilt...@gmail.com mailto:billy.stilt...@gmail.com wrote: So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k thats why i say fix tcl/tk my old graphics library could be used for a new gui. it is c++ but has the logic to even only update lines as in blit an arbitrary line. On Tue, Mar 4, 2014 at 1:33 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: On 03/04/2014 01:20 PM, Jonathan Wilkes wrote: On 03/04/2014 10:11 AM, i go bananas wrote: [...] 2014-03-04 12:12 GMT+01:00 i go bananas hard@gmail.com mailto:hard@gmail.com: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations. Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element. So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent. I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta. I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm I don't have sound on that clip, but I believe I tried it with the test audio patch going and I wasn't getting dropouts
Re: [PD] Get name of patch from within the patch
On 03/04/2014 03:00 AM, Kaj Ailomaa wrote: On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote: Hello, On 03/03/14 21:55, Kaj Ailomaa wrote: Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this? I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch]. Thanks, but this won't work for me, as the name has to be the actual patch name. I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch. The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way. I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem. Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork. -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] Pd as sound editor (issue with scrolling a table) ??
On 03/04/2014 10:11 AM, i go bananas wrote: [...] 2014-03-04 12:12 GMT+01:00 i go bananas hard@gmail.com mailto:hard@gmail.com: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations. Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element. So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent. I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd as sound editor (issue with scrolling a table) ??
On 03/04/2014 01:20 PM, Jonathan Wilkes wrote: On 03/04/2014 10:11 AM, i go bananas wrote: [...] 2014-03-04 12:12 GMT+01:00 i go bananas hard@gmail.com mailto:hard@gmail.com: just for interest perhaps, here's the sound editor i made years ago: http://puredata.hurleur.com/sujet-1295-sound-editor and probably even more interesting, here is maelstorm's wave display abstraction: http://puredata.hurleur.com/sujet-5890-waveform-display basically, what maelstorm discovered was that using [until] with a counter was not nearly fast enough to do the calculations needed for a decent zoom/scroll function, and we looked into it, and there just didn't seem to be a vanilla workaround. So he uses iem_tab objects to do the table calculations. Remember that when you redraw an element of an array you actually redraw the _entire_ array in Pd Vanilla. And depending on the array style you may have a separate tk canvas item for each element. So when you use the [until] loop you are sending drawing instructions to the GUI ($arraysize * $no_mouse_events) times. A single array redraw instruction in tcl is about 4k, so to scroll a single pixel for a 100-element array: 100 elements * 1 = 100 redraws * 4k = 400k That's flowing from the core to the GUI for a _single_ mouse event. If you trigger ten scrolls you're already at 4 megs of data sent. I'm pretty sure commercial editors avoid that type of design. In editors like the upcoming Openshot Video that have several discrete parts that sending messages, the GUI part almost certainly sends nothing at all to the video core for zooming/scrolling. For moving a chunk of audio/video, it almost certainly sends a single message about a single object's delta. I may have showed this already, but I think it's instructive here: https://jwilkes.nfshost.com/pd-tiger.webm I don't have sound on that clip, but I believe I tried it with the test audio patch going and I wasn't getting dropouts. This is because a) I'm sending a single transform message for every scroll of the number box and b) the GUI toolkit-- not Pd core-- is doing the math to transform and redisplay the drawing. Socket traffic is bad because it require both the core (sending) and GUI (receiving) to do work. If you generate megs and megs of traffic you can end up with dropouts and choking display even if there's very little being redrawn. -Jonathan -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] Get name of patch from within the patch
On 03/04/2014 01:15 PM, Ivica Bukvic wrote: ...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet. There's also [patchname $1( | [duplicate_effort] Just fill $1 with the name of the object you want to create, and [duplicate_effort] will automatically compile another class with that name and with the functionality you want. Currently [duplicate_effort] supports the following methods: patchname dollarargs abs~ pow~ bandlimited_grabbag arraysize mousecoords count string duplicate_effort Each class created is guaranteed to be unique so you can use it to create private keys. You can also give it an extra float argument to specify help patch quality. (All values default to zero.) To download a copy, start a repo in github and code up another version of it. -Jonathan On Mar 4, 2014 12:47 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: On 03/04/2014 03:00 AM, Kaj Ailomaa wrote: On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote: Hello, On 03/03/14 21:55, Kaj Ailomaa wrote: Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this? I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch]. Thanks, but this won't work for me, as the name has to be the actual patch name. I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch. The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way. I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem. Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork. -Jonathan ___ 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 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
Re: [PD] Get name of patch from within the patch
But it also precedes the search-plugin. -Jonathan On Tuesday, March 4, 2014 3:59 PM, Ivica Bukvic i...@vt.edu wrote: Except that in this case patch_name precedes canvasinfo... On Mar 4, 2014 3:01 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 03/04/2014 01:15 PM, Ivica Bukvic wrote: ...and [patch_name] external (again pd-l2ork only) that outputs the filepath out of the left outlet and the patch filename out of the right outlet. There's also [patchname $1( | [duplicate_effort] Just fill $1 with the name of the object you want to create, and [duplicate_effort] will automatically compile another class with that name and with the functionality you want. Currently [duplicate_effort] supports the following methods: patchname dollarargs abs~ pow~ bandlimited_grabbag arraysize mousecoords count string duplicate_effort Each class created is guaranteed to be unique so you can use it to create private keys. You can also give it an extra float argument to specify help patch quality. (All values default to zero.) To download a copy, start a repo in github and code up another version of it. -Jonathan On Mar 4, 2014 12:47 PM, Jonathan Wilkes jancs...@yahoo.com wrote: On 03/04/2014 03:00 AM, Kaj Ailomaa wrote: On Tue, Mar 4, 2014, at 02:54 AM, Chris McCormick wrote: Hello, On 03/03/14 21:55, Kaj Ailomaa wrote: Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this? I would use [namecanvas] for this. For example you could have an object like [namecanvas $0-mypatch] and then you can send messages to the patch using e.g. [s $0-mypatch]. Thanks, but this won't work for me, as the name has to be the actual patch name. I've understood that there might be a fix in the svn version of [canvasname], apart of iemguts, which would allow getting the name of the top level patch. The reason I had for this is I wanted to have uniquely named patches that have a common save mechanism, which looks up the savefile based on the unique patch name. I was always going to create these uniquely named patches in another top level patch, so I can get around this problems by adding an argument for the patch, which is the same as the patchname, and let the save mechanism look up the filename that way. I initially would have wanted the uniquely named patch to be able to be opened as is, but that's not a major problem. Currently I think the only way to do this is [filename(---[canvasinfo], which is only in Pd-l2ork. -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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Get name of patch from within the patch
In Pd-l2ork, you can do [filename(---[canvasinfo]. But I'm still working on that interface. For example, itgives you the name without the extension .pd. But maybe it should include that extention, too. In Pd-extended, I'm not sure how to do that. There's [iemguts/canvasname], but it doesn't give return anything for a toplevel patch. -Jonathan On Monday, March 3, 2014 9:11 AM, Kaj Ailomaa zeque...@mousike.me wrote: Hi. I've been googling a bit and looking through the library of objects that comes with pd-extended, but can't seem to find a way to get the name of the patch from within the patch. Anyone know of a nice method to do this? ___ 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 as sound editor (issue with scrolling a table) ??
On 03/03/2014 02:44 AM, Billy Stiltner wrote: seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb. You can make a wave editor. You just cannot make a wave editor that has the tools typically found in commercial wave editors, unless you systematically ignore the modern/sophisticated GUI systems which make commercial wave editors efficient to use. -Jonahan https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.com%22sort=-publicdate On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimas...@gmail.com mailto:pimas...@gmail.com wrote: Hi Jonathan, I found it following this path : help for [tabwrite] -- More_Info -- all_about_arrays -- Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true... Cheers, Pierre. 2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com: From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42. I did the refactoring of that patch, but I'm not sure who wrote what you're quoting. I'd say that statement is false and should be removed. -Jonathan On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimas...@gmail.com mailto:pimas...@gmail.com wrote: Dear list, I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content. I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached. I have 2 questions : 1) Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it. This leads me to a more general question about something i've found in the help : 5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors. This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd. Cheers, Pierre. ___ 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 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
Re: [PD] Pd as sound editor (issue with scrolling a table) ??
On 03/03/2014 01:32 PM, Pierre Massat wrote: I've looked seriously at data structures for the first time, and saw what Chris McCormick did with them, and I believe this is the way to go ! But you can't get notifications for mouseover or right-click events. You also cannot get transparency or control the z-order among multiple scalars. Nor scale or zoom without creating another complex and slow wrapper on top of data structures. Don't get me wrong-- you can do interesting things with scalars, and you can build a wave-editor that looks quite advanced compared to what a GUI in Pd typically looks like. But you cannot get anything that looks remotely like a modern or even decade-old commercial wave-editor. So I'd rather the documentation didn't send people searching around the corners of the software for features that don't exist. -Jonathan Cheers, Pierre. 2014-03-03 8:44 GMT+01:00 Billy Stiltner billy.stilt...@gmail.com mailto:billy.stilt...@gmail.com: seems like there was something about the way i made the wave editor that worked,i never tried overflowing the the things and my method is a hack of the pd file @xensynth and the lfo editor, otherwise holler at Mike Booth ala mmb. https://archive.org/search.php?query=uploader%3A%22billy.stiltner%40gmail.com%22sort=-publicdate On Mon, Mar 3, 2014 at 2:34 AM, Pierre Massat pimas...@gmail.com mailto:pimas...@gmail.com wrote: Hi Jonathan, I found it following this path : help for [tabwrite] -- More_Info -- all_about_arrays -- Common uses for arrays in Pd Bummer, I thought somebody would come up with a secret table manipulation technique that would make this statement true... Cheers, Pierre. 2014-03-02 19:33 GMT+01:00 Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com: From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42. I did the refactoring of that patch, but I'm not sure who wrote what you're quoting. I'd say that statement is false and should be removed. -Jonathan On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimas...@gmail.com mailto:pimas...@gmail.com wrote: Dear list, I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content. I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached. I have 2 questions : 1) Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it. This leads me to a more general question about something i've found in the help : 5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors. This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd. Cheers, Pierre. ___ 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 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
Re: [PD] jack and callbacks
On 03/03/2014 07:44 PM, Peter P. wrote: Hi, just learned that my Pd vanilla Pd-0.45.0 from Miller's Git sources works much better (less drop outs, etc) under jack when enabling use callbacks. Is there a way to enable this worthy parameter from the command line? Perhaps a way of setting it statically, maybe in s_audio_jack.c ? Is there any documentation about enable callbacks outside of being littered throughout the list? Two more questions: Isn't Jack's API callback-based? What does it mean to use Jack without enabling callbacks? -Jonathan Thank you and enjoy! Peter ___ 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 as sound editor (issue with scrolling a table) ??
From that help patch: #X text 12 115 HELP_PATCH_AUTHORS Updated for Pd 0.38-2. Jonathan Wilkes revised the patch to conform to the PDDP template for Pd version 0.42. I did the refactoring of that patch, but I'm not sure who wrote what you're quoting. I'd say that statement is false and should be removed. -Jonathan On Sunday, March 2, 2014 10:47 AM, Pierre Massat pimas...@gmail.com wrote: Dear list, I am working on a small patch which stores simple events in a table to trigger sounds later on. I would like to be able to edit the content of my table easily, which requires scrolling it, zooming in, and eventually editing the content. I have found away of scrolling the content, but it is very slow with relatively big tables (hem, even with a table with 20 000 samples...). Please see the example attached. I have 2 questions : 1) Is there a more efficient way of doing this ? Copying only part of the content is worse (i've tried). 2) Can I prevent the content of the table from spilling over the table to right of the left ? I get the same behaviour in a GOP, and putting a canvas next to the table to cover it doesn't work because the table content gets redrawn on top of it. This leads me to a more general question about something i've found in the help : 5 Wave editing: with proper manipulation of array data, Pd can be fully functional wave editor, complete with mouse-clickable cut-n-paste, pitch-shift, time expansion, down/upsampling, and other tools typically found in commercial wave editors. This has always sounded very appealing to me, but i wonder how realistic this statement is... unless i'm ignoring 80 % of what can be done with tables in Pd. Cheers, Pierre. ___ 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
the details of why there's a Pd-l2ork and how it's different from Pd-extended, but if no one is willing to say they will do the work of listening, reviewing, and delegating work on an upstream core then we're just dancing around the real problem. -Jonathan Cheers, Peter On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner billy.stilt...@gmail.com mailto:billy.stilt...@gmail.com wrote: 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 http://home.comcast.net/%7Epatslabtech/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 mailto: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 mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ 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
Re: [PD] easing in pd
I refactored a bunch of the easing styles from Raphael.js to use with data structures (attached). Look in [pd movers] and then [pd animate]. The patch itself only works in Pd-l2ork, but you can break out all of the animation logic. You'll just need to replace any instance of [pi(--[pdinfo], with the value of Pi. (I should probably get rid of that anyway.) Here's a video: jonathanwilkes.net/easing.webm On Wednesday, February 26, 2014 4:00 PM, Alexandros Drymonitis adr...@gmail.com wrote: The mapping library is very likely to have stuff that would be helpful to you, I guess.. On Wed, Feb 26, 2014 at 10:42 PM, David Schaffer schafferda...@hotmail.com wrote: Hi , I was wonderning if anyone of you had tried to implement easing in pd. I'm working on a video animation patch that uses random objects and the result would look much better if I could find a way to smooth the transitions. I already use the line object, but I'm looking for a way to slow down the line output when the line comes to its end, then start smoothly when it has a new target value. I'm thinking of using the expr object but I would be grateful if someone could give me some design hints on this... Thank you very much, D.S http://www.flickr.com/photos/schafferdavid/ https://soundcloud.com/schafferdavid ___ 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 easing.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bugs in Pd-Extended in Ubuntu LTS
1) Are you starting JACK before firing up Pd-extended? 2) Are you typing any non-ascii characters? If so what are they? -Jonathan On Tuesday, February 25, 2014 1:54 PM, Pierre Massat pimas...@gmail.com wrote: Dear list, I've been using Pd-extended in Ubuntu LTS (12.04) a lot lately, and a couple of bugs are beginning to get on my nerves... first it randomly crashes and also crashes X (i get a black screen, and after a few seconds i'm prompted for my password to log into my session again), whenever I'm typing something in an object box (i haven't been able to figure out exaclty what character was causing this, it really looks random to me). I also get constant error messages in the console when using JACK (JACKerror: Cannot use real-time scheduling (RR/55)(1: Operation not permitted) JACKerror: JackClient::AcquireSelfRealTime error). The sound works sometimes though, but Pd also freezes every once in a while. I also get error messages with Alsa. I have installed Pd-extended from the Ubuntu repos. It seems to be the same version as the one available on puredata.info (0.43.4). I don't know what to do. Cheers, Pierre. ___ 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
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 Pd
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] libpd separating gui from core
On 02/23/2014 07:37 AM, Dan Wilcox wrote: On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed. This is probably naive, but wouldn't it suffice to have an object that does automatically what the user is forced to do manually atm? Manual -- user opens a Pd instance for GEM and a separate Pd instance for audio Auto -- user creates an object [foo-audio-magic somepatch.pd] which automatically fires up a separate instance-- _not_ a child of the first-- for the audio. Also, what is the metric to use here? Mmm open a larger patch with audio running, momentary dropouts. How do you know that's due to Pd's single-threadedness, and not some CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI calculations in the core thread as well as tk's thread? Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you meaningful metrics but their impression may be along the lines of not only does this program look old, but it keeps clicking when I'm dragging things around. Etc etc That particular problem is due directly to *_getrect calls in a patch with lots of objects (and possibly a bunch of *_click calls if hovering over an object that does a lot of computation in such a function). It's not super easy to solve, but it's approachable because the Pd-GUI already exists. But that's a completely separate issue from getting something like GEM to run in its own thread. Things maybe acceptable to us PD grey beards, but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to just add more cores years ago now, so it's not like buy a faster machine is going to magically solve single threaded speed issues. It's not acceptable, but if you want to move forward _and_ do work that will be in sync with or accepted into Pd vanilla I don't see a way forward. I can't even get help docs into Pd vanilla, and they were written to the PDDP spec that this community came up with and approved. And as you know, there's a publicly viewable list of the same exact frustrations from all kinds of developers with various styles of communication. At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Did you use any of the Pd-l2ork versions before it moved to Tkpath? It didn't solve the *_getrect problem I mentioned above, but it solved a whole lot of the problems that cause dropouts while editing, mainly by shooting way fewer messages across the socket. Anyway if you're interested in coding anything up related to this thread, I know Ivica is interested in solving the GEM issue you mentioned. -Jonathan Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI. enohp ym morf tnes -- 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
On 02/23/2014 08:15 PM, Ivica Bukvic wrote: On Sun, Feb 23, 2014 at 4:40 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: On Feb 23, 2014, at 3:29 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: Yeah, stuff like that we should be able to solve. I'm not for ditching the Tcl/Tk gui at all. The work you and Ivica have been doing seems to be going a long way to fix this. Great! I just really hope this goes back into vanilla somehow or can be split up into between libpd and a gui implementation, etc. Otherwise, I fear a return to DD. If I may chime in for a sec (pd-l2ork author here), there is absolutely no interest in dropping development of pd-l2ork anytime soon. Pd-L2Ork already has thousands of lines of code either altered or added and I have no intention of slowing down. Likewise, in part because I tried in the past, I have no interest in trying to get things merged into the core pd. I will very much welcome someone else's efforts to do so but knowing Miller's gargantuan goal of keeping backwards compatibility, I simply feel this approach is too time consuming for me to promote the rate of development I (and as it appears many others on this list) desire. Additionally, DesireData never had any stable releases as far as I remember. matju may have used it for some of his projects, but when I played around with it there were major chunks of functionality missing, and easy crashes. If someone wanted to port over DD's keyboard-only patching feature to Pd-l2ork, for example, you'd very quickly see the difference between the two. Because once it makes it into a release you'd be using the feature in a piece of stable software. That's an enormous difference. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] core - gui question
Hi list, I've got a nice little method for an info class in Pd-l2ork that tells whether an x/y coordinate lies within an object on a particular canvas. For the new svg-style drawing commands I've added, this method makes it possible to do some fairly simple tests within a patch to make sure I don't break things along the way. For example, I can check the bbox of scalars that contain transformed shapes, or check to make sure that the stroke-width is contained within the bbox, check positions of gop scalars, nested data structures, etc. If the gui and core were truly separated, how would I do these tests within Pd? To follow the Pd message-passing model, I need to get an answer to my query in zero logical time. If the bbox data is only held by the gui then I have to send a request over the socket, and the object chain will have finished computing before the gui sends back its data. If the core holds a synced copy of bbox data then the gui must either a) constantly bombard it with updated values or b) send a message that tells the core what got updated and let the core update data for all relevant objects. In which case there's no longer really a separation between gui and core. On a related note-- for the new drawing commands I'm doing all kinds of crazy calculations in the core for stuff like getting the bbox of an svg path. It's ridiculous because all that math has already happened in Tkpath, but I can cache it so Pd doesn't take a huge performance hit. But I simply couldn't figure out a way to get that data from the gui in a way that doesn't cause all kinds of syncronization problems. By the time *_getrect is called the core must already have the bbox data, otherwise it's too late. Is there some way to deal with that without moving the entire gui logic out of the core? I couldn't think of one. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] threads in pd, dataflow
On 02/21/2014 10:04 PM, Simon Wise wrote: On 22/02/14 06:28, Jonathan Wilkes wrote: On 02/21/2014 06:41 AM, Simon Wise wrote: Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order. [...] Even the dsp-gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. To know whether a control branch interacts with the signal domain is to solve the halting problem, no? But you could have some kind of seal object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way). It could look like a wax seal and always be at the top-left of the patch. -Jonathan ___ 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'm just having trouble with the specifics. Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Also, what is the metric to use here? To compare apples to apples, imagine that every g_* sourcefile has already been moved to the GUI side of both the single- and double- threaded designs that are being compared. -Jonathan On Sunday, February 23, 2014 12:30 AM, Rich E reakina...@gmail.com wrote: On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes jancs...@yahoo.com wrote: On 02/20/2014 09:50 PM, Rich E wrote: On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.com wrote: On 02/18/2014 11:11 PM, Rich E wrote: On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com wrote: 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. IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime. The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation. What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI? Firstly, I think the decision should at least be available (to process audio and GUI on separate threads), since this is the most common way to handle the two different update rates. Especially since, with most GUI frameworks, you _must_ update the GUI on the main / UI thread, which is running at 60fps. But to answer the question... drawback is having to manage the whole 'this method must to be called on the audio thread, and that method must be called on the non-audio thread'. However this turns out to be little of a limitation since it is almost always what you want to do anyway, and you gain huge amounts in the area of responsiveness. In the end, every situation is different. With pd vanilla, audio is most important and maybe that deserves the current architecture. To me, it is more about keeping options open, which is why I think abstracting the visual position from the core is a good idea.___ 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 02/20/2014 09:50 PM, Rich E wrote: On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: On 02/18/2014 11:11 PM, Rich E wrote: On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: 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 mailto: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. IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime. The GUI and audio shouldn't be updated from the same thread. This is one nice thing about libpd, it forces a separation. What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI? So in this type of world, the GUI can do whatever it needs to do in order to draw at the desired framerate, and flags graph changes along the way. In Pd-extended and Vanilla currently there is very little optimization to get the most out of Tk. Those problems have a tendency to get lumped in with single-threadedness. So if someone actually gets something with a better design up and running, just remember that you have to do similar optimization work before the benefits of the new system really start to shine. Otherwise you'll get burned out when the right approach still gets dropouts-- from the odd inefficient algorithm, some standard widget that eats CPU for lunch, or whatever else isn't documented on the shiny frontpage of the toolkit. -Jonathan The changes are then converted into a GUI-agnostic format and synchronously issued to the audio context. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] t_scalar member sc_vec
On 02/21/2014 09:00 AM, Ivica Bukvic wrote: Because this way you can reference data points with sc_vec+n as opposed to dealing with single or double linked lists (since sc_vec can be an array). If sc_vec is a pointer then you can access data points using the same technique, which is pointer math after all. For everyone's amusement, here's an exercise in my own rank speculation: something about a t_word array aligning on boundaries in a way that you wouldn't be able to guarantee with a pointer to a t_word. So if you can guarantee there won't be padding you save memory in 1981. Is it something like that, Miller? And do scalars actually go back to 1981, or that's just around the time you learned the technique? Also-- this technique means that for sc_vec[1] its position inside the struct suddenly become relevant. That is, if you put sc_template as the last member field you'd be indexing into the wrong place when you tried to read/write sc_vec data. Is that right? -Jonathan On Feb 21, 2014 7:26 AM, Charles Goyard c...@fsck.fr mailto:c...@fsck.fr wrote: Hi, Sorry for this question, but why isn't sc_vec a good old pointer ? t_gobj sc_gobj; /* header for graphical object */ t_symbol *sc_template; /* template name (LATER replace with pointer) */ t_word sc_vec[1]; /* indeterminate-length array of words */ } t_scalar; How is a static t_word array of size 1 an indeterminate-length array? Is its placement as the last member of the struct required? ___ 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 02/21/2014 06:41 AM, Simon Wise wrote: On 21/02/14 20:41, Charles Goyard wrote: Hi, just to give some example of single vs multi-threaded, and some comparison points. - projects like haproxy and lighthttpd show that good state machine programming can be more efficient that multi-threaded programming, even on multi-core computers. BUT they handle a much reduced number of use cases. - graphics chipsets are massively parallel. They handle huge amounts of data. BUT they are hard to build, they also handle a much recuced number of use cases, CUDA and OpenCL being a generalization. - (on windows) has its core single-threaded, and a lot of objects are multi-threaded, just like pd. It suffers the same than pd: when you get interactive with the GUI, the framerate slows down dramatically. - whitecat (a DMX software) has its GUI that runs on OpenGL, and it's not that efficient. In the case of PD, maybe just a good mix of libpd and a generalization of pd~ can improve things much. [pd~] deals with the particular case of creating an extra dsp thread, it incurs overhead to do so and does not isolate the dsp from a busy patch. It is quite orthogonal to creating separate gui, video, audio or whatever threads. What I guess you mean is very different .. an object to launch a distinct pd process within (and isolated from) the rest of a pd patch. But I am not sure how that would be any better or more human-readable than 2 pd instances with [netsend]s and a suitable script to launch them together. Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. -Jonathan 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
[PD] t_scalar member sc_vec
Can anyone explain what's going on with this in m_pd.h:
typedef struct _scalar /* a graphical object holding data */
{
t_gobj sc_gobj; /* header for graphical object */
t_symbol *sc_template; /* template name (LATER replace with pointer) */
t_word sc_vec[1]; /* indeterminate-length array of words */
} t_scalar;
How is a static t_word array of size 1 an indeterminate-length array? Is its
placement as the last member of the struct required?
I see lots of mysterious casts in the internals of Pd's data structures.
What's the trick here, and is it documented anywhere on the interwebs, a C
standard doc, etc.?
Thanks,
Jonathan___
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 02/18/2014 04:00 AM, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-02-17 22:42, Jonathan Wilkes wrote: No sane person is going to do incremental work without a plan on GUI software in 2014 that only has a single undo. luckily the work on the GUI will most likely happen in git, which gives you infinite undo. The question is whether a highly capable dev who isn't already entrenched in Pd development would see participation as worthwhile or a waste of time. What I'm saying is that without a clear plan, no sane developer is going to undertake the work of adding infinite undo, various GUI improvements, or anything else that can't ship as an external. But yes, technically you can use Git to do yet another GUI rewrite if you wish. -Jonathan fmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTAyE4AAoJELZQGcR/ejb4p20P/0v4ZnEhRhzuLBzl3Jr8bGRC FSp04pTFlgdIqYPvJJooQA2vWJPHCOcHNPI7u8kDJk3tr+1p1EQ41apK6qFw/xU5 E1093htLiZojq2OCMMO9ZOYbm0DXZZHRmo6nMcG2GXceqCSNA3OMw7p4MRGyVJB1 tS/gyckHowInGDif+3eYKSD6iTZcBFpa/QahaT9kZzTk6HQ4hRtoro5OZ/z97nj6 ILJsDv0xK01I4MF1s9OUsMdVp6itTCI9irHYOMr1IeNbhQMaZrT1z2HtqG9q8NZs Q4p6uKGtGgqIZU5noCrmLnxVde0HlirpxSIDzq+FHJ4b9dQk9pJSI+zKTE8hCs1O sCUFZNi2udd9NwkaAqs1/2msf15WO+GmguMZXzaOiOxcx9FKrVE03IATZ4vqLNCd AucU9dxohcYrqPuzzBhfxmmYk6aLwPaZpamezTeBNCni0qn25X5ZwDWY6YHnd5fO Ck1yvhWKO0g5jVH2Tx4iAgnceKVqe++q5q+XnR8goFPFvxPC3THCGoGaIx4FSgea Zcfy3VymCWByyG57K2yV2R+wr3qwK8TDligtM0XoUB+a0caYr6uq5qMnOTzOJpIt GpwrWerw1957a/ccxpkNpofh4HPosg0oeYRajc1mELY07bLcahgMaIGxIevxvub2 00RL1CEc36ySA5xLzcsd =M/8o -END PGP SIGNATURE- ___ 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 02/18/2014 11:11 PM, Rich E wrote: On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox danomat...@gmail.com mailto:danomat...@gmail.com wrote: 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 mailto: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. IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime. Actually even in 2d without audio the problems manifest themselves pretty quickly. For example: open the svg tiger inside Inkscape and move it around. Notice the clever trick-- the image is broken into tiles and moved starting with the pieces closest to the mouse. Since the user's eye focuses on the mouse pointer, the interaction looks snappy even though it may take half a second or more to finish moving the tile furthest from the pointer. When you add realtime audio the options are either to err on the side of sluggishness or to be responsive and risk dropouts. If you want it to be responsive in both video and audio then you have to start doing some serious optimizations based on what you think the user cases are for the software. For example, the Inkscape trick is perfect for creating and manipulating vector graphics, but it would be terrible for a 2d animation environment where you'd presumably want the tiger to move as a single unit. However, many of Pd's current problems don't have a lot to do with that. Tk is pretty good at being sluggish and avoiding dropouts when it doesn't have idle time to do graphics updates. In fact I can move around an svg tiger on a canvas without interrupting the test audio patch. Most dropouts related to the GUI have to do with what amounts to a DDOS attack from the core to the GUI. When you flood tcl with data from the socket it can't really do anything else but spend time receiving it. When you add that to whatever Pd core is doing to generate all those messages in the first place, you probably won't have any time left over for delivering audio. Other toolkits are certainly more efficient than Tk. But if you're dragging an antialiased wire from the top left of the window to the bottom-right, the toolkit needs time to do those redraws. Finally, I'm not really sure how Open-GL and hardware acceleration plays into all this. For example, Qt Graphics View docs have a note about accelerated graphics possibly adding a performance hit and possibly more latency, but it's only in the context of hardware that doesn't do floating point computations efficiently. I played around with Kivy a bit, which is hardware accelerated but honestly didn't see much of an improvement in cpu usage over comparable stuff in Tkpath. -Jonathan cheers, Rich ___ 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 02/17/2014 10:48 AM, Hans-Christoph Steiner wrote: I think that the way forward with the pd/gui separation is to work on the low hanging fruit, things that are easy to fix. Let the hard parts for later, which will only be a couple areas. So that means looking at everywhere where sys_gui() or sys_vgui() is called, and seeing how the raw Tcl in those calls can be converted into Tcl procs. The syntax for calling Tcl procs is very close to a Pd list, so that is an easy way to get close. The Pd dev community has always been plagued with a desire for grand plans before starting work. And that has proven to mean nothing happens. No sane person is going to do incremental work without a plan on GUI software in 2014 that only has a single undo. -Jonathan .hc On 13/01/2014 15:32, 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. ___ 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] Wich licence?
On 02/15/2014 03:14 PM, olm-e wrote: On 15/02/14 20:53, pd-list-requ...@iem.at wrote: Date: Sat, 15 Feb 2014 16:52:58 -0300 From: Mario Mey mario...@gmail.com Subject: Re: [PD] Wich licence? To: pd-list@iem.at Message-ID: 52ffc59a.4030...@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 14/02/14 15:45, Jonathan Wilkes wrote: How would that be any different than spyware? -Jonathan Haha! Good point! Thanks everybody for the answers. I took a look to Matt Davey's DIY2 effects and he put no license txt file on its folder. Maelstorm mmb libraries have no license too... My patch is for everyone who wants to use it or learn with it. If someone finally uses MEH-SYSTEM or a modified version of it in stage or for a video or whatever... I would like to know it... only that! Maybe I leave it as is. Saying nothing about license... Skim the Wikipedia pages for GPL and 3-clause BSD, choose the one you prefer, and then you're done. Otherwise you create potential work for anyone who may have a use for your software to figure out what the terms of use and distribution are. It's probably not a big deal for a particular piece of software, and there are plenty of Pd patches out there that don't specify anything. But when you take, say, everything that exists on Github, the lack of licenses probably leads to busywork that eats up measurable amounts of time and effort. -Jonathan -- Hello, having no licence is probably not a good idea, as it's like enforcing the default copyright rules that basically give no rights at all ... (lots of code are practically not legaly usable on github for that reason f.ex.) the best would be IMHO to put it in (L)GPL and gently ask to downloaders to report use as a courtesy on the download page... have a good day, Ol. ___ 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] Wich licence?
On 02/14/2014 08:16 AM, Mario Mey wrote: I made a Multi-FX Looper called MEH-SYSTEM, posted in PD Forum: http://puredata.hurleur.com/viewtopic.php?pid=37430 I want to put a license to it. Where should I get information about types of licences? I don't think in any restriction... I only would want to know where, when, how and by-who it was used. Only that. How would that be any different than spyware? -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] increasing zone of inlet / outlet
You'd have to tweak the stuff in g_text.c and probably also g_rtext.c to lie about the rectangle size, and to enlarge the bbox for what gets counted as an xlet, then recompile. Meanwhile, there's a single tk canvas subcommand called -closeenough that does exactly what you want. But Pd doesn't use that-- it only fowards mouse motion over the socket to Pd. Then Pd core queries the bounding box of every object on the canvas, to see whether it falls within the mouse coordinates. It does this for _every_ single motion message received from the gui. (Run pd with the -d 3 flag to see how often these messages get sent.) -Jonathan On Thursday, February 13, 2014 4:30 PM, pured...@11h11.com pured...@11h11.com wrote: Hi all, I am getting older and it's more and more difficult to click right on the inlet or outlet. How to change increase the zone around them? I am using PD-0.43.4-extended. 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] increasing zone of inlet / outlet
On 02/13/2014 10:27 PM, Ivica Bukvic wrote: In pd-l2ork nlets are highlighted which makes them grow and as a result you can pinpoint them more easily. In k12 learning mode they are even bigger to help kids select them. HTH That's after you register a hit. But can you actually register a hit when the mouse is within n pixels of the xlet? I ran into this with the svg-data structures stuff. I made some points on a graph grow when the mouse enters them. But it turns out it's much more usable if you have an insible area larger than the point to register an enter event and then grow the point to that size. -Jonathan On Feb 13, 2014 5:23 PM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: You'd have to tweak the stuff in g_text.c and probably also g_rtext.c to lie about the rectangle size, and to enlarge the bbox for what gets counted as an xlet, then recompile. Meanwhile, there's a single tk canvas subcommand called -closeenough that does exactly what you want. But Pd doesn't use that-- it only fowards mouse motion over the socket to Pd. Then Pd core queries the bounding box of every object on the canvas, to see whether it falls within the mouse coordinates. It does this for _every_ single motion message received from the gui. (Run pd with the -d 3 flag to see how often these messages get sent.) -Jonathan On Thursday, February 13, 2014 4:30 PM, pured...@11h11.com mailto:pured...@11h11.com pured...@11h11.com mailto:pured...@11h11.com wrote: Hi all, I am getting older and it's more and more difficult to click right on the inlet or outlet. How to change increase the zone around them? I am using PD-0.43.4-extended. 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 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
Re: [PD] Is open source better?
To answer your last question: have a look at webpd: https://github.com/sebpiq/WebPd There's a simple demo patch here: http://sebpiq.github.io/WebPd/sound-check/sound-check.html That's Pd's basic audio engine and message passing system running in javascript. So in terms of open source, the efficiency is undeniable. To run Max/MSP in a web page, they'd have to figure out some complex way to protect their proprietary code while still making it possible to make sounds by adding a script in the html. The only practical thing I could think of is running a centralized service, but again that costs money and maintenance where a decentralized lib like webpd runs on the user's device. Addressing the oddity of using proprietary software (IOS) to point out the benefits of open source: Unfortunately the open source definition was designed to subtly hide the ethical reasons for doing open source development. The reasoning for this was quite straightforward-- share with your neighbor doesn't attract business dollars. So open source advocates focus on efficiency, like the ability to plug a 3-clause BSD-licensed library into just about any device you want, even a device that is locked down and requires the final app to be proprietary. This is equivalent to teaching the scientific method, but downplaying the importance of reproducibility for some seemingly practical purpose. If enough scientists are weak on such a fundamental aspect of their job due to bad education it will degrade their ability to carry out meaningful, reproducible experiments. So open source advocates can't have it both ways. If they purposely exclude the golden rule and user freedom from their marketing materials because it's such a drag, I don't see how they can complain when the efficiency of their dev model takes users and business to places the initiative didn't want them to end up. Whether it's Google's centralized services or Apple and Android smartphones that spy on the user, you can't fight back if you aren't willing to state the fundamental principle that users must be free to determine how the devices they own actually operate. If anyone wants to read a principled statement on user freedom, it's here: http://www.gnu.org/philosophy/free-sw.html -Jonathan On Sunday, February 9, 2014 9:24 PM, Simon Wise simonzw...@gmail.com wrote: On 10/02/14 11:53, Pall Thayer wrote: I'm giving a presentation this week. In a way, it's a counter argument to a recent presentation on Max/MSP. One of the things that I want to highlight is the open sourceness of PD. libpd presents a very good argument and I'll be highlighting a project I was involved with that produced an IOS app that used libpd as the audio engine. Is there anything else I should be considering besides the obvious points of open source being open source. Concrete examples of PD's open sourceness trumping proprietary technologies? IOs is an odd choice for talking about open source when the only way to install such an app in a device (without jailbreaking it or paying the developer tithe) is by licensing the binary closed source (on their terms) to Apple to distribute via their platform-monopoly app store, which will not distribute the sources or GPL or LGPL apps? Certainly licenses such as libpd's BSD like one do allow reuse of the code in any app, open source or otherwise, but then is that use still open source??? 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] Is open source better?
On 02/10/2014 05:31 PM, Simon Wise wrote: On 11/02/14 04:40, Jonathan Wilkes wrote: Unfortunately the open source definition was designed to subtly hide the ethical reasons for doing open source development. The reasoning for this was quite straightforward-- share with your neighbor doesn't attract business dollars. So open source advocates focus on efficiency, like the ability to plug a 3-clause BSD-licensed library into just about any device you want, even a device that is locked down and requires the final app to be proprietary. If you consider attracting business dollars actually spent on ongoing development of open source code then the GPL, explicitly stating its aims and with strict copyleft terms has been quite successful (not denying that BSD, Apache and similar have also, in many cases) That's true, but an open source advocate could still reframe that in terms of efficiency, cost-savings, etc., rather than freedom for the end user. An open source advocate could even make the argument that the GPL actually gets in the way even for the most successful projects that are licensed with it, creating unnecessary bureaucracy and copyright sign-off requirements in what would otherwise be a post-license digital utopia. I don't buy those arguments, but the point is that if there are enough voices framing everything in those terms then fundamental principles about user freedom get lost. I mean, if I'd never heard much about freedom of the press then who knows if I'd find it reasonable to prosecute journalists who receive classified information and sell it to their publishers in the form of news. Instead, that sounds like tyranny to me. And that's more likely due to a long line of teachers with the integrity to explain those principles than to living in a country licensed under the Constitution. :) -Jonathan If anyone wants to read a principled statement on user freedom, it's here: http://www.gnu.org/philosophy/free-sw.html -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] Infinite Permissions Loop
On 02/10/2014 05:43 PM, Wesley Boynton wrote: No such luck, unfortunately. All pd-related programs have the necessary permissions, yet I am still stuck in the loop. Thanks a bundle, ~W On Mon, Feb 10, 2014 at 5:37 PM, Simon Wise simonzw...@gmail.com mailto:simonzw...@gmail.com wrote: On 11/02/14 08:24, Wesley Boynton wrote: Hello, all! I am currently using PD-Extended in both OSX 10.8 and 10.9 environments. On our administrator accounts, we installed X11 and everything went fine. It launches and all is well. However, in our primary user accounts, we're greeted with a You don't have permission to use the application 'Pd-extended' dialog. Repeatedly. No matter how many times I grant it permission on an always or one-off basis, it continues to pop up the same dialog until I surrender and click OK. I don't understand-- if you surrender by clicking Ok to the dialog then where is the infinite loop? Does the main Pd console window come up? -Jonathan This is, by the way, all despite the fact that PD and X11 are on the list of Parental Control-Approved applications for use. Any input would be extremely appreciated and valuable. maybe you need Wish and/or Pd-extended and/or pd-gui or something on that safe list as well? ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ~Wesley Boynton http://www.wesleyboynton.com CELL: 703-635-0839 ___ 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] How to get a list of midi devices without GUI
In Pd-l2ork you can also do this: [print( | [pdinfo] Which prints all the info for the running Pd instance to the console, including devices. Or you can send it a message to get a specific attribute like [audio-outdev, midi-outdevlist( | [pdinfo] I tried it with [loadbang] and -nogui, and all the audio devices display properly. I can't test midi because I don't have any midi devices. -Jonathan On Sunday, February 9, 2014 10:49 AM, Antoine Villeret antoine.ville...@gmail.com wrote: hello again, I found the issue, with `-nogui`, the patch is loaded before midisettings are done (like audiosettings) and `[mediasettings/midisettings]` updates it's own device list on startup or on `[device ...(` message. So when the patch is loaded at startup without gui, `[mediasettings/midisettings(` records 0 mididevices. I have to send a dummy `[device ...(` message 1sec after loadbang to update the list and then `[listdevices(` report the right number of devices. Another solution could be to delay the patch loading. Shouldn't `[mediasettings/midisettings]` update it's own device lists on `[listdevices(` message ? + A -- do it yourself http://antoine.villeret.free.fr 2014-02-09 16:17 GMT+01:00 Antoine Villeret antoine.ville...@gmail.com: thanks, but no, at least with Pd Vanilla 0.45-4, the right flag is *-listdev* to list all devices (both midi and alsa) in the PD's console. According to this 10-years old post [1], I can still make a redirection of stderr or read at it. Another solution, since my problem concern only Linux, is to read the output of `ls /dev/midi* | wc -l` to get a list of mididevices, but this doesn't tell if it's input or output. + a [1] : http://lists.puredata.info/pipermail/pd-list/2004-10/023368.html -- do it yourself http://antoine.villeret.free.fr 2014-02-09 16:08 GMT+01:00 Pagano, Patrick p...@digitalworlds.ufl.edu: I think it's just --listdevices on the command line Sent from my iPhone On Feb 9, 2014, at 10:03 AM, Antoine Villeret antoine.ville...@gmail.com wrote: Hello, I'm wondering how to get a list of midiout devices without GUI. This has to work without GUI. I tried [mediasettings/midisettings] but it always report 0 devices (both in and out) when there is no GUI. i also know the -listdev option to Pd, but this only list devices in console, and I need to proccess the number in the patch. I observe this on Linux (both Ubuntu 12.04 64bit and Raspbian (kernel 3.10.25+) with pd 0.45-4. But it seems to be OK on MacOS with pd 0.45-3. Thanks Antoine -- do it yourself http://antoine.villeret.free.fr ___ 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] check mail with pd ?
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm.
But it's irrelevant to getting decent string manipulation within Pd,
meaning using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string hello{world}
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] cryptocurrency and pd
I would be a little cautious about this. If you ended up implementing something that garnered wider interest, you'd raise the reward for attacks on normal Pd users and on Pd community infrastructure. That'd be a major burden for Pd users-- keeping an eye out for me.grimm@blah vs me.grim@blah, running patches in a virtual machine, having to learn GPG... That last one makes me shudder. -Jonathan On Saturday, February 8, 2014 10:38 AM, me.grimm megr...@gmail.com wrote: maybe our own Pdcoin w/ mining ability only through/with Pd externals/patches m On Thu, Feb 6, 2014 at 4:09 AM, i go bananas hard@gmail.com wrote: Has anything been done to try to marry these together yet? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- m.e.grimm | m.f.a | ed.m. megr...@gmail.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] check mail with pd ?
On 02/08/2014 01:40 PM, Martin Peach wrote:
A few years ago I implemented a patch for strings in Pd that adds a
string or blob type that allows (I think) for what you are describing.
I believe it's still part of Pd extended, but Miller didn't like it
for some reason.
It looks more like a prototype for a string implementation. I'm not
even able to do this:
[bng]
|
[str hello_world]
|
[print]
Additionally, moving the cord-inspector over the wire connecting
displays nothing. Those are just the first two things I tried to do as
a user, to view a core atom type which most of the time will be holding
readable text.
It may seem trivial to get those two things to work, but the point is
that someone has to do it, for every single internal and external class
which already understands and can manipulate the one string atom but
doesn't understand the better string atom.
[str hello 32 world] isn't much fun, either. But it's hard to improve
that without the ability for the object box to leave the user input
unparsed.
I prefer to manipulate strings in a another language as it just seems
like a lot of work to make it happen with boxes and wires when you can
just call string functions in a high level language.
I don't understand this. If you take nearly every string manipulation I
did in tcl for the search-plugin and put it in Pd, you are either a)
unrolling several commands in nested square brackets and laying them out
vertically (or inside an abstraction) or b) putting a tcl line of code
in a box and connecting its output to the next line of tcl code in a box
with a wire. If a is troublesome to patch and read in Pd then it was
hard to write and read in tcl.
There are of course way more complex examples of string manipulation,
but Pd's tools don't have to be perfect to be useful.
Kind of like building a Turing machine holes-in-paper-tape version of
a program, it can be an interesting exercise but practically it's
useless.
Read in transcript of congressional testimony on NSA surveillance.
Split into one string for each line.
Read one line every second.
If a line contains the word terrorism make a sound.
User takes a drink.
Totally useful. :)
What is it about boxes connected with lines that you think makes this
difficult?
-Jonathan
Martin
On 2014-02-08 03:14, Jonathan Wilkes wrote:
On 02/08/2014 01:26 AM, Martin Peach wrote:
You can manipulate strings in pdlua and only export the symbols you
want; yes you need to learn lua but it's not very hard.
That's good practical advice for getting work done with strings atm. But
it's irrelevant to getting decent string manipulation within Pd, meaning
using boxes connected with wires.
The reason for wanting to do string manipulation within Pd is just as
obvious as the question that I didn't have to ask and which you
addressed after your semicolon.
-Jonathan
Martin
On 2014-02-08 01:10, Jonathan Wilkes wrote:
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd
extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string hello{world}
around in Pd, I should not have to know the codes for curly braces
just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the
user
to type strings that get saved underneath as character codes, as
well as
display lists of character codes as a string in the patch. I don't
know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read
from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation
tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are
the
reason for introducing lists of character codes. Otherwise you're
just
pushing the current problems users have with symbols to the edges
of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/08/2014 11:44 PM, Simon Wise wrote: On 09/02/14 07:59, Jonathan Wilkes wrote: On 02/08/2014 01:40 PM, Martin Peach wrote: A few years ago I implemented a patch for strings in Pd that adds a string or blob type that allows (I think) for what you are describing. I believe it's still part of Pd extended, but Miller didn't like it for some reason. ... I prefer to manipulate strings in a another language as it just seems like a lot of work to make it happen with boxes and wires when you can just call string functions in a high level language. ... Kind of like building a Turing machine holes-in-paper-tape version of a program, it can be an interesting exercise but practically it's useless. Read in transcript of congressional testimony on NSA surveillance. Split into one string for each line. Read one line every second. If a line contains the word terrorism make a sound. User takes a drink. Totally useful. :) What is it about boxes connected with lines that you think makes this difficult? Perhaps it is the long term and very well established resistance to adding a few types to the message syntax ... integers capable of indexing reasonable file lengths, strings which don't flood the symbol table, floats that aren't in danger of being truncated, bytes or chars which won't trigger parsing issues. Matrices are available via an external library (gridflow, within its own externals including non-native print and so forth) and GPU video access is possible via GEM with its private message syntax, but core Pd is very focussed on what it originally set out to do. There have been some moves on this, just very slow and careful ones. A graphical dataflow language is very nice for dealing with DSP and with control and interaction logic, and for doing so in a bunch of machines distributed over a network. Pd has lots of good ways to receive and send control messages and link with hardware and other programs. But dataflow and procedural algorithms are quite different and parsing strings is a very common thing to do when programming ... if you are familiar with the procedural way and have a good set of tools available to abstract the details then its easier to just go with what you know. It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd. It sounds like you are rationalizing and encouraging non-development. But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text. -Jonathan 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] check mail with pd ?
On 02/06/2014 01:53 AM, Chris McCormick wrote:
On 06/02/14 06:29, pured...@11h11.com wrote:
but pd is not really good with strings afaik
Maybe soon:
https://sourceforge.net/p/pure-data/pure-data/ci/8a02332a5fb68edc2899e2f13513c77f0796d21b/
https://sourceforge.net/p/pure-data/pure-data/ci/49ffcf8ba5cdde7660e82f1e190fcee7c6fa5627/
:)
One of the reasons (I think) the string manipulation libs in Pd extended
haven't caught on is because they seem to force users to care directly
about character codes. If I want to pass the string hello{world}
around in Pd, I should not have to know the codes for curly braces just
to create that string in an object box.
To work, this will require a new set of GUI classes that allow the user
to type strings that get saved underneath as character codes, as well as
display lists of character codes as a string in the patch. I don't know
any externals that do this, but it shouldn't be hard if you're sending
the text to the GUI as floats. Also, you need i/o classes to read from
and write to files without having to pass through lists of symbols and
floats as intermediaries. Otherwise, you will lose data on the read.
Finally, you can't leverage any of the extant symbol manipulation tools,
because then you run into symbol-table growth, dollsym
substitutions/escapes, and all the other problems that I assume are the
reason for introducing lists of character codes. Otherwise you're just
pushing the current problems users have with symbols to the edges of the
new string library.
I understand the desire for this approach, and it's probably less work
than making symbols deallocatable. But if the user has to stare at
character codes just to get around the limitations of symbol atoms,
they'll probably just use symbol atoms and work within Pd's current
limitations for string processing.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Legal restrictions for apps
On 02/05/2014 08:56 PM, Simon Wise wrote: On 06/02/14 00:36, Dan Wilcox wrote: Short answer: yes, it's sufficient to provide the object files and static libs As far as my understanding of GPL LGPL goes, you do not need to publish your app sources when using LGPL libraries as the Lesser part of the LGPL allows for distribution and is not viral. yes, though 'viral' is a misleading term ... the GPL does not, cannot, change any license for any other code, it is not infectious. The GPL is certainly more restrictive (regarding re-distribution, not use, of the code covered) than for example the BSD or LGPL. It restricts the right to distribute/propagate as part of a larger work to works where the whole of the source code of that work is made available for reuse, modification and re-distribution either under the GPL or in any less restrictive way. In the second case the GPLed code would no longer be licensed for distribution (and would have to be replaced or dropped or a different license negotiated with its copyright owners) if the work as a whole was modified and distributed with a more restrictive license. Whether this is useful or not has been very widely debated. There are two debates. One is between devs who license their code with the GPL and devs who license their code with 3-clause BSD. Both share what they make with the world. Both keep publicly auditable databases of the changes to the software. Both encourage smart, safe ways to design and maintain software and operating systems. BSD devs notice that when they share with GPL devs, the GPL devs say, Thanks. But when the BSD devs try to use what the GPL devs write they have to fuss with the license. This is because the GPL essentially puts the golden rule into the license, whereas the BSD devs have a minimal license (probably as minimal as a license can be) and just follow the golden rule as human beings. There are good reasons for both camps to do what they do, but it ends up requiring the BSD folks to care more about licenses than they'd like-- their license is only 3 clauses, after all! So the BSD camp complains that when the GPL devs (like Linux Kernel devs) improve on code that was originally BSD, it comes back to the BSD folks infected with the GPL license which requires them to then care about licenses. This is where the viral taunt comes from-- a genuine argument between two camps, both sharing what they make with everyone else to encourage a free and safe software ecosystem. Another debate is between any company that produces proprietary software and a straw man in a corn field. Here viral is irrelevant because the company isn't giving improvements back to the community. Unfortunately this is probably what first pops to mind when people hear this argument-- that, somehow, the GPL can infect the business of selling a product and make it impossible for a company to make money. But for better or for worse, we don't even need to consider minimal moral principles. It's demonstrably dangerous to rely on software that doesn't have a pubic codebase and revision history. (Unfortunately I think it's for the better since most devs seem allergic to stating minimal moral principles.) -Jonathan The motivation for the GPL is stated in the license and the LGPL was written to cover some cases where the authors considered a less restrictive license useful. 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] cryptocurrency and pd
In what way? You should theoretically be able to visualize a proof-of-work block-chain as a dataflow diagram, for example. But generally speaking, Pd doesn't seem like it can offer much since it would be quite slow to do hashes or cryptographic functions. -Jonathan On Thursday, February 6, 2014 4:09 AM, i go bananas hard@gmail.com wrote: Has anything been done to try to marry these together yet? ___ 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] cryptocurrency and pd
On 02/06/2014 11:03 AM, i go bananas wrote: In what way? that's what i want to know! I don't know the specifics, but I think both cryptography and finance are areas where the feature of everything is a float actually gets in the way. In either case you cannot afford to lose precision. But you can prototype some of the features of a cryptocurrency in Pd. For example, Bitcoin uses the hashcash algorithm to verify each block of the transaction database. (If I understand it correctly it's like brute-forcing SHA256 keys, although they never completely succeed.) The miners basically start a counter, do a mathematical function on the value plus the previous value from the last entry in the transaction database, and finally check if the output has a certain number of leading zeros. If you ignore for the moment the counter and the mathematical function, you can see how the process works. Attached is a patch that just keeps spitting out pseudo-random numbers between 0 and 1 until all of the [random] objects happen to output zeros. It's essentially like a slot machine that keeps playing until you win. Now notice that when you hook up another [random] to the chain you double the average time it takes to find a winner. Add enough [random] objects to the chain and you will quickly hit a point where you can't compute a winner at all (even if you change the patch to compute answers as fast as possible). Bitcoin's block difficulty uses the same principle. The software has a hardcoded rule that it should take 10 minutes to find a winner. But instead of using a bunch of binary values, it uses a single number and requires the winner to be below a certain value (which is equivalent to counting the leading zeros in the representation of the number). Over a certain number of days it measures the average time it takes the network to compute a winner. If it's way less than 10 minutes on average then the software automatically does the equivalent of adding a [random] to the patch to make it twice as hard. If it takes too long then the software removes a [random]. The actual algo is probably more sophisticated but that's what it boils down to. Now, let's say you hook up 50 [random] objects in that patch and happen to find a winner. That'd be pretty spectacular, but how do you convince everyone that you are being truthful about your claim? This is where the hashing function and the counter come into play. Instead of the attached patch, imagine a [hash] abstraction that takes a counter value in the left inlet and the previous transaction hash in the right inlet. It will output a seemingly unrelated number in response to the input, but that number will be unique to the input you give it (or so close to unique that we can just call it unique). That's what a hashing function does. So you essentially do the same thing you did above, except you're looking for leading zeros in a single number rather than the collective output of a bunch of [random] objects. When you hit a winner you then broadcast your counter value and the new transactions to the rest of the network to add to the database. The rest of the network already has the previous entries in the transaction database, so they can take those with your counter value and verify that the resulting hash actually has the correct number of leading zeros. Then everyone starts working on the next winner. And why do they do that instead of trying to lie and say they were the one that actually found the winner? Because the first new transaction in the database is the real winner giving 50 bitcoins to themselves, and that transaction uses public key cryptography to ensure that it can't be forged or changed. One last thing-- the hashing function is designed so that it's extremely difficult (read: impossible) to start with a hash value that has the required number of leading zeros and work backwards to figure out the right counter value. Like a slot machine, you have to just keep trying until win. And just like a slot machine, if someone can figure out how get a winner without putting in the same work/money everybody else does, then the entire system breaks down. -Jonathan #N canvas -9 19 708 498 10; #X obj 176 44 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X obj 176 65 metro 50; #X obj 176 172 random 2; #X obj 178 218 +; #X obj 246 172 random 2; #X obj 316 172 random 2; #X obj 178 255 +; #X obj 178 446 moses 1; #X obj 46 99 t a; #X obj 386 172 random 2; #X obj 178 286 +; #X obj 456 172 random 2; #X obj 526 172 random 2; #X obj 176 86 t b b b b b b b; #X obj 596 172 random 2; #X obj 178 327 +; #X obj 178 368 +; #X obj 178 413 +; #X text 356 114 connect more to increase the difficulty; #X text 358 271 ... and connect them here \, too; #X obj 46 137 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X connect 0 0 1 0; #X connect 1 0 13 0; #X connect 2 0 3 0; #X connect 3 0 6 0; #X
Re: [PD] cryptocurrency and pd
On 02/06/2014 02:08 PM, Charles Goyard wrote: Hi, i go bananas wrote: In what way? that's what i want to know! If that's a general question, then the answer is yes, as you can get and send bytes over a network and do math with pd. It's also the answer for all general questions like can I do something a computer does with pd ? It does not mean it fits you needs, or the amount of work you want to put in :). Not giving contexts does not lead to useful answers. That's a self-fulfilling prophecy. It also turns out to be wrong, because I made another self-fulfilling prophecy which turns out to be useful. -Jonathan So, do you have something in mind ? ___ 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] cryptocurrency and pd
Pd or otherwise, I'd be very careful about sending any messages back and forth with the actual Bitcoin network. By doing so you are essentially telling the internet that fungible, irreversible tokens might exist on your machine, the value of which could far exceed anything that you have ever or will ever store on your computer. Also, blockchain.info likes to store the IP of the first node that told it about a transaction. It's pretty well connected, so if you make a transaction from your machine your IP is very likely associated forever with that transaction. (Just one of many ways in which Bitcoin is not anonymous.) But of course if you happen to be in Sochi then everything of value on your machine has already been stolen, so knock yourself out. :) -Jonathan On Thursday, February 6, 2014 5:59 PM, Thomas Mayer tho...@residuum.org wrote: On 06.02.2014 10:09, i go bananas wrote: Has anything been done to try to marry these together yet? PuREST JSON includes a sonification for Bitcoin values going back to 2011, but I guess, that is not what you wanted to know. 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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] check mail with pd ?
On 02/05/2014 05:29 PM, pured...@11h11.com wrote: yes possible, for example using py/ext with a script like this one: http://libgmail.sourceforge.net/ but pd is not really good with strings afaik If you use Pd and have a use case where you're controling both the sending and receiving of the messages, then you can limit the message content to use only what Pd's message parser can handle. Also, make sure the machine you're using has never had or will never have anything of interest on it. On the other hand, I guess you could leave a Bitcoin wallet on there and think of your impending hack as a virtual Halloween treat. -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] console font size really big
On 01/30/2014 06:26 PM, Miller Puckette wrote:
Better than changing the font size globaly would be to change the
font sizes in tcl/pdwindow.tcl to negative numbers, which has the same
effect but only locally (instead of nuking everything. The particular one
is:
text .pdwindow.text -relief raised -bd 2 -font {-size 10} \
-highlightthickness 0 -borderwidth 1 -relief flat \
-yscrollcommand .pdwindow.scroll set -width 60 \
-undo false -autoseparators false -maxundo 1 -takefocus 0
(change size 10 to size -10.)
Now I should think about whether to do that in the Pd source :)
That's a difficult choice. On the one hand you'll get console output
with similar sized font on each platform. (Not pixel-exact btw because
that depends on the font renderer.) On the other you'll cause problems
for the visually impaired who really do want point-sized fonts.
Of course the latter point only holds _if_ tcl/tk reports a sane number
for [tk scaling]. That's probably not the case for OSX, and who knows
for various GNU/Linux distros. But I haven't looked to see whether this
is remedied in tk 8.6.
Btw, for those exploring other GUI toolkits for Pd: choose QT. It is as
cross-platform as anything could be, has an enormous userbase, great
documentation, and a _friendly_ community. I cannot stress that last
point enough. If someone disagrees please try porting Pd's GUI to GTK;
after you burn out from trying to deal with Gnome devs I'll buy you a beer.
-Jonathan
cheers
Miller
On Fri, Jan 24, 2014 at 06:25:23PM -0500, Jonathan Wilkes wrote:
On 01/24/2014 05:31 PM, Peter P. wrote:
Johnathan WIlkins wrote:
I'd be curious to know what window manager you are using.
Try going into pd-gui.tcl and find the line:
# tk scaling 1
Remove the #, save the file, and then restart Pd. See if that
solves the problem.
(Depending on how you are running Pd, you may need to have privileges
to edit that file)
-Jonathan
I am using fluxbox.
Indeed, editing /usr/local/lib/pd/tcl/pd-gui.tcl to yield
tk scaling 1
solved the problem for me.
Interestingly there is a file /usr/local/bin/pd-gui.tcl present as
well, whose changes do not have an effet. This Pd is installed using
make install from within Miller's git sources. I wonder why
pd-gui.tcl is installed twice on my system, the latter one also being
in my $PATH.
Thank you again for this quick one Jonathan.
There is a comment related to tk scaling in this very file just above
the scaling option:
# we are not using Tk scaling, so fix it to 1 on all platforms. This
# guarantees that patches will be pixel-exact on every platform
# 2013.07.19 msp - trying without this to see what breaks - it's
# having
# deleterious effects on dialog window font sizes.
Would be interesting to know wonder what the deletrious effects were.
Tk has a very friendly but very small community without the
resources to make sure everything works as advertised across all
platforms. So depending on which platform you use you'll see
different symptoms, depending on how well tk is integrated with the
guts of the window manager (in GNU/Linux, this would be not at
all), the accuracy of the info delivered to Tk from the OS/window
manager, implementation features/bugs in a particular graphics
subsystem, etc.
One detail is that if you let [tk scaling] do its thing, you'll see
problems in the postscript output if you print a patch. There's an
ugly fix somewhere for this which requires hacking the ps output to
scale it by the tk scaling factor.
But if you hard code tk scaling to 1 users on Windows will see font
problems from Tk's half-baked, hardly documented theming engine that
would require _really_ ugly hacks all over Pd to fix.
-Jonathan
But, hey- problem solved for me.
thanks
cheers
P
___
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] comments with trailing | ?
On 01/24/2014 05:36 PM, Miller Puckette wrote:
Delete these lines in g_text.c:
/* for comments, just draw a bar on RHS if unlocked; when a visible
canvas is unlocked we have to call this anew on all comments, and when
locked we erase them all via the annoying commentbar tag. */
else if (x-te_type == T_TEXT glist-gl_edit)
{
if (firsttime)
sys_vgui(.x%lx.c create line\
%d %d %d %d -tags [list %sR commentbar]\n,
glist_getcanvas(glist),
x2, y1, x2, y2, tag);
else
sys_vgui(.x%lx.c coords %sR %d %d %d %d\n,
glist_getcanvas(glist), tag, x2, y1, x2, y2);
}
(however, that won't disable the functionality; just the ugly marks.)
I'm still trying to think of something less ugly - tell me if you have any
ideas...
Just to give a concrete example, something like:
else if (x-te_type == T_TEXT glist-gl_edit)
{
if (firsttime)
sys_vgui(.x%lx.c create rect %d %d %d %d
-dash {1 3}
-tags [list %sR commentbar]\n,
glist_getcanvas(glist), x1, y1, x2, y2, tag);
else
sys_vgui(.x%lx.c coords %sR %d %d %d %d\n,
glist_getcanvas(glist), tag, x1, y1, x2, y2);
}
Then you have a visual clue that the user is in editmode, with no
ambiguity between the drawing and the text.
You can play with the dash values-- I chose those because it gives a
clear contrast to broken boxes. Use a larger 2nd integer to make the
dashed box stand out less.
Btw-- I haven't tested this. I'd be a lot more likely to try out code
on Pd Vanilla 0.45 if someone could explain to me how to do incremental
builds. If I change a single line in g_text.c in 0.43 it only requires
a single make that takes about 3 seconds. Doing the same in 0.45
requires make clean make, unnecessarily rebuilding all of Pd.
Doing make in the src directory of 0.45 only rebuilds the things that
need to recompile, but it doesn't update the binary, which makes it useless.
-Jonathan
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Software Defined Radio in Pd
On 01/30/2014 06:41 AM, Julian Brooks wrote: Hey all, I've come across something I'd like to share with everyone. Video demo http://newblankets.org/video/Software%20Defined%20Radio%20in%20Pd.webm (bit fuzzy but you'll get the drift) The patches are here: github: https://github.com/tkzic/pdsdr This from the github page: 'What is this? Here's a video of the basicSDR3.pd patch running with a soft66LC2 SDR: http://youtu.be/6sH6-DTU14E Patches are running PdExtended 0.43-4 on MacOS. Although you will probably find you can get it run in Pd vanilla with tweaks. The project is based on tutorial patches for the Max/MSP SDR project at: http://zerokidz.com/radio - They are documented at that site. Externals: The source code is kind of a disaster. Please don't ask how to compile. We just figured out how to get this running in Pd a few days ago.' Huge props to Tom Z for doing this. I spoke to Tom briefly last week and he said that he has no time due to work commitments to deal with this again for another month or so, so I think it would be better if we left him alone for a bit. There's a ton of stuff online to explain the concept further so for those interested I'd recommend some digging about. The creative potential for applications of this concept are vast (I'm still getting my head around it to be honest). He thought that it would be relatively trivial to turn the receiver into a transmitter which'd be pretty awesome. Is there an extant decentralized system that can keep everyone's SDR-capable devices from interfering with everyone else's SDR-capable devices? -Jonathan Even just making creative use of the endless variety of soundsources constantly transmitted unbeknownst to us is plenty for me to be getting on with. But yeah, what an ear-opener. Regards to all, Julian ___ 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 GUI freeze with error message(Tcl)
On 01/29/2014 01:08 PM, Ivica Ico Bukvic wrote:
I've seen these also happen when something tries to address a non-existent
widget (e.g. when it is being closed or something similar).
There are a few things:
1) Weird treatment of the tk error window in OSX. It looks like
sometimes it causes an infinite loop, but I can't predictably generate
the error.
2) If I understand it correctly, the tk event loop can run into the same
problem the Pd audio dsp scheduler runs into with when you have too many
calculations per dsp tick. But it's worse with tk because it isn't
optimized for doing timely graphics updates in the first place. If you
are sending a constant stream of just enough data to the gui that tk no
longer has any idle time to update graphics, then you may get yourself
into a situation where tk never updates and you see a freeze.
Moreover, tk seems not to use its idle time very efficiently. I built a
recursive loop for the search plugin specifically to let the user
interact, cancel operations while building a search index. But you can
see how inefficient its drawing routine is. (Maybe this has to do with
X11 as well, but I think the sluggish redrawing happens on OSX too.)
This all is particularly problematic when combined with Pd's
architecture, because it's often sending a barrage of messages to the
gui. For example:
* an error message to the console. The console is fairly snappy when
dealing with an email's worth of text, not so snappy when dealing with
100 error messages being sent every 10ms.
* moving a large number of objects in Pd-extended or Vanilla
* moving an array in Pd-ext or Vanilla
* resizing an array where each element of the array is an svg tiger
-Jonathan
There is an easy
way to prevent this from ever stopping GUI from working by encapsulating all
commands streaming from pd-gui with a simple catch{command}. This is what
in part pd-l2ork does and I cannot remember when was the last time I had a
problem like this.
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Miller Puckette
Sent: Wednesday, January 29, 2014 12:29 AM
To: Jonghyun Kim
Cc: pd-list@iem.at
Subject: Re: [PD] Pd GUI freeze with error message(Tcl)
Hi Jong -
I think the *(Tcl) INVALID COMMAND NAME' stuff isn't related to Pd
freezing,
but I'd like to find out how it happens and fix it.
The GUI can freeze if Pd is overloaded with audio computation on Mcintosh
compuers - the only thing I can suggest is reduce the amount of audio
computation (I know - nobody would ever want to do that :)
cheers
Miller
On Wed, Jan 29, 2014 at 04:03:17AM +0100, Jonghyun Kim wrote:
Hi list,
I don't know why this cause, but sometimes it appears and GUI freeze,
but
still Audio alive. Only GUI die...
Number Box, Vu meter, Sliders, and so on, these GUIs all stop, and
don't
show the actual numbers...
Anyone knows this issue?
--
*(Tcl) INVALID COMMAND NAME: invalid command name .x4de9a0.c*
*while executing*
*$tkcanvas itemconfig $tag -text $text*
*(procedure pdtk_text_set line 2)*
*invoked from within*
*pdtk_text_set .x4de9a0.c .x4de9a0.t395fcb0{98.13}*
*(uplevel body line 19)*
*invoked from within*
*uplevel #0 $docmds*
--
Pd-0.45-4 (32bit)
Mac OS X Mavericks
Screenshot attached.
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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Data structures and their clickable area
On 01/29/2014 05:40 PM, Roman Haefeli wrote: On Mon, 2014-01-27 at 21:34 -0500, Jonathan Wilkes wrote: On 01/27/2014 05:35 PM, Roman Haefeli wrote: Hi I'm using a template consisting of a rectangle done with [filledpolygon] and a number [drawnumber] in it. While mouse clicks anywhere in the area of the rectangle are detected, it's only possible to change the number with the keyboard when I exactly click on the number. Is there a way to make the number catch the keyboard no matter where I click in the rectangle? One possibility is to make the hotspot bbox settable. Actually, something like this would be on my wishlist. Knowing it does not exist yet, I hoped for some kludge solution. It would literally be five minutes of dev time. But I'm not sure it's the ideal solution since often you want a hotspot to exceed the formal bounds of an object, and this wouldn't do that. Still, I'll code it up and see how it works. Or maybe have a method to forward widgetbehaviors to another drawing command. Would certainly be interesting too, though having the hotspot area be configurable would make this less important. Probably best to just fool around with Raphael.js or some such library to see what it does, and see what can be ported. -Jonathan Anyway, thanks for your thoughts. 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] Data structures and their clickable area
On 01/27/2014 05:35 PM, Roman Haefeli wrote: Hi I'm using a template consisting of a rectangle done with [filledpolygon] and a number [drawnumber] in it. While mouse clicks anywhere in the area of the rectangle are detected, it's only possible to change the number with the keyboard when I exactly click on the number. Is there a way to make the number catch the keyboard no matter where I click in the rectangle? That's not possible. Essentially what you want is to take a click from one draw command-- [filledpolygon]-- and map it or forward it to another-- [drawnumber]. Scalars don't give you any tools to hook in to a parent drawing command's widgetbehavior that way. Similarly, I'd like to be able to mouse-drag anywhere in the rectangle in order to change the value of the number. You could probably do it if you use a field variable to define hotspots on every 6x6 tile of the rectangle. But you'd also have to constrain movement of the rectangle by abusing the quanta syntax, something like (-whatever:whatever)(0:0). That would presumably constrain the field variable's screen coordinates so that it doesn't move when you click-drag it. Then use the same field variable for your [drawnumber]. I'm almost finished with some new drawing instructions for data structures in Pd-l2ork that implement a subset of the svg spec. I've got some mouseover/mouseout widgetbehaviors working, but still nothing particularly sophisticated in terms of mapping mouse/keyboard interaction to field variables. One possibility is to make the hotspot bbox settable. Or maybe have a method to forward widgetbehaviors to another drawing command. -Jonathan Any ideas? 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] console font size really big
On 01/24/2014 05:31 PM, Peter P. wrote: Johnathan WIlkins wrote: I'd be curious to know what window manager you are using. Try going into pd-gui.tcl and find the line: # tk scaling 1 Remove the #, save the file, and then restart Pd. See if that solves the problem. (Depending on how you are running Pd, you may need to have privileges to edit that file) -Jonathan I am using fluxbox. Indeed, editing /usr/local/lib/pd/tcl/pd-gui.tcl to yield tk scaling 1 solved the problem for me. Interestingly there is a file /usr/local/bin/pd-gui.tcl present as well, whose changes do not have an effet. This Pd is installed using make install from within Miller's git sources. I wonder why pd-gui.tcl is installed twice on my system, the latter one also being in my $PATH. Thank you again for this quick one Jonathan. There is a comment related to tk scaling in this very file just above the scaling option: # we are not using Tk scaling, so fix it to 1 on all platforms. This # guarantees that patches will be pixel-exact on every platform # 2013.07.19 msp - trying without this to see what breaks - it's # having # deleterious effects on dialog window font sizes. Would be interesting to know wonder what the deletrious effects were. Tk has a very friendly but very small community without the resources to make sure everything works as advertised across all platforms. So depending on which platform you use you'll see different symptoms, depending on how well tk is integrated with the guts of the window manager (in GNU/Linux, this would be not at all), the accuracy of the info delivered to Tk from the OS/window manager, implementation features/bugs in a particular graphics subsystem, etc. One detail is that if you let [tk scaling] do its thing, you'll see problems in the postscript output if you print a patch. There's an ugly fix somewhere for this which requires hacking the ps output to scale it by the tk scaling factor. But if you hard code tk scaling to 1 users on Windows will see font problems from Tk's half-baked, hardly documented theming engine that would require _really_ ugly hacks all over Pd to fix. -Jonathan But, hey- problem solved for me. thanks cheers P ___ 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] was confused about $1 in messages; finding last error
Here are some hints: 1) If the thing that caused the error isn't a gobj (i.e., if it's not a comment, object, iemgui, etc.), then Pd probably doesn't know how to select it. For example: [namecanvas c] [abc( | [s c] Or: [abc( | [s pd] 2) There are two error interfaces in Pd that I know of: pd_error and error. pd_error stores a pointer to the last thing that caused an error. I guess an external writer could technically store a pointer to anything there, but when you try to find the last error it assumes it was a gobj. Then there's plain old error, which prints out the word error: to the Pd window followed by whatever the error is. This is how the argument number out of range error works. There's no reference to the thing that caused the error, so you cannot search for it using Find last error. Unfortunately it looks like pd_error can't be used because the error is caught in the midst of Pd parsing the message (in binbuf_eval of m_binbuf.c). At that point it doesn't look like it keeps track of the object which sent the message. Perhaps it could highlight the next object which would have received the message, I'm not sure. -Jonathan On Thursday, January 23, 2014 9:23 AM, ro...@dds.nl ro...@dds.nl wrote: thanks everyone for answering, and for explaining my persistent blind spot. i stumbled over it, because of a patch which gave continuously an error message no method for 'abc'. but 'finding last error' always said 'sorry...'. my question: is there any useful (hidden) info in this message/fact, that Pd sees the error but can't tell where it happened? rolf ___ 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] access to archives
You can also download the entire archive linked in the top-left corner. http://lists.puredata.info/pipermail/pd-list/ It's in a format called mbox that predates various forces attempting to remake the internet in the style of cable-tv (who btw are succeeding, at least in the U.S.). The archive gives you the content you're after, and you decide how you want to present it. (Yet another dream of the early web pioneers that's dying a slow death.) You can import that mbox file into _any_ email application and it will make sense of it because it's an international standard format for email. There are tutorials for doing this with Thunderbird-- essentially just putting the mbox file in the correct directory and opening the application. Then it will appear and you can browse/search/reorg all those Pd list messages like any other email message. Finally, make a filter to put new incoming Pd-list messages there and you're done. Thunderbird may suggest archiving the thing because it slows down searching, but a slow local search is still faster than the average search on Gmane. You can also download any Thunderbird plugin to display the messages in a newsgroup style, with threading, and all kinds of other options that essentially let you present the messages however it suits you. Unfortunately, this means the Pd-list server has to take a hit while you download the archive. It'd be nice if the Bittorrent protocol had been expanded in the past decade to handle files that grow over time. But again, there is a very real battle against all technology and infrastructure that distributes content at zero cost. So this is the next best thing. -Jonathan On Thursday, January 23, 2014 8:03 AM, Py Fave pyf...@gmail.com wrote: is it possible to improve the archive of pd-list ? currently if a discussion spreads on a few monthes , you can't follow it. and it would be easier to have a common interface to use all the informations that sleep inside.(sorting by type of content (such as gem, control, audio for instance) i feel it would be useful. to complement the documentation since many discussions are in there make it a forum ? just thinking loud . pierre-yves ___ 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
