[PD] web patching
Hi people,just a bit weird question...is there any other (graphical) way to create PD patches than the provided tcl/tk interface? Specially, a way to patch from a web page (?)... By the way, do you think Pd can handle dynamic instancing of audio patches without audio dropouts? What specific tricks could help with it? I know audio is interrupted when the DSP tree is rebuilt, but I don't know exactly whether this always happens and if there are some techniques to avoid it. I need a way to keep audio running while an user is adding or removing some audio-processing abstractions. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] openstomp ... PD pedal?
So what about a Raspberry Pi inside a stompbox that runs pd? It's relatively cheap. Perhaps you can use the gpio to do some nobs, switches, buttons etc. But could the arm11 in that thing handle awesum audio processing? ;) alexander On Sat, Mar 3, 2012 at 7:41 AM, Billy Stiltner billy.stilt...@gmail.com wrote: sounds like lemmings On Fri, Mar 2, 2012 at 9:35 PM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Billy Stiltner billy.stilt...@gmail.com Cc: pd_list Listserve pd-list@iem.at Sent: Friday, March 2, 2012 6:30 PM Subject: Re: [PD] [OT] openstomp ... PD pedal? Le 2012-03-02 à 17:37:00, Billy Stiltner a écrit : you should be able to get a 486 on a pinhead these days How many 486 can dance on the head of a pin ? http://en.wikipedia.org/wiki/How_many_angels_can_dance_on_the_head_of_a_pin%3F Until no more angels can fit on the pin, send more angels to the head of the pin. When you're done, stop. But most importantly-- if you can't stop, don't start. -Jonathan 486dx, of course. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] C++ for reusable dsp lib - or better use C?
On Sat, Mar 3, 2012 at 12:57 AM, Thomas Grill g...@g.org wrote: How about function call overhead? For constructor and destructor no problem of course, but accessor wrappers will be called often, in fact it doubles the number of function calls for external access. I would not worry about that too much. The potential number-crunching happening in your routines will most probably outweigh that small member calling overhead. If your methods are real lightweight (and they are defined in an included - not a linked - file) you can still rely on a decent compiler to inline them, bashing overhead to zero. I fail to see how those C wrappers could be inlined. Wouldn't that undo their raison d'être (replacing a C++ call with a C call)? But indeed function call overhead is small when compared to number-crunching, if these calls are done per block and not per sample. So it could be done like this: write a lib in C++ with C++ API, and additionally provide C wrappers for the API functions. Then it's up to the application programmer to use the C wrappers or call C++ functions directly. That seems convenient, apart from other issues as mentioned by Hans and Mathieu. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] openstomp ... PD pedal?
That's all I'm asking. Pierre 2012/3/3 dreamer drea...@puikheid.nl So what about a Raspberry Pi inside a stompbox that runs pd? It's relatively cheap. Perhaps you can use the gpio to do some nobs, switches, buttons etc. But could the arm11 in that thing handle awesum audio processing? ;) alexander On Sat, Mar 3, 2012 at 7:41 AM, Billy Stiltner billy.stilt...@gmail.com wrote: sounds like lemmings On Fri, Mar 2, 2012 at 9:35 PM, Jonathan Wilkes jancs...@yahoo.com wrote: - Original Message - From: Mathieu Bouchard ma...@artengine.ca To: Billy Stiltner billy.stilt...@gmail.com Cc: pd_list Listserve pd-list@iem.at Sent: Friday, March 2, 2012 6:30 PM Subject: Re: [PD] [OT] openstomp ... PD pedal? Le 2012-03-02 à 17:37:00, Billy Stiltner a écrit : you should be able to get a 486 on a pinhead these days How many 486 can dance on the head of a pin ? http://en.wikipedia.org/wiki/How_many_angels_can_dance_on_the_head_of_a_pin%3F Until no more angels can fit on the pin, send more angels to the head of the pin. When you're done, stop. But most importantly-- if you can't stop, don't start. -Jonathan 486dx, of course. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] web patching
Hi there, for web patching the most promising project so far is Chris McCormick's and Co WebPd: http://mccormick.cx/projects/WebPd/ As for audio dropouts with dynamic patching, there have been several discussion on the list (i.e. check the archive). This might be one of the best shots: http://lists.puredata.info/pipermail/pd-list/2011-08/090385.html An easy solution is to detect the onset of a DSP graph change and stop the audio for few milliseconds, then activate it again. You can use messages to Pd to do this, such as: [; pd dsp 1( [; pd dsp 0( M Hi people,just a bit weird question...is there any other (graphical) way to create PD patches than the provided tcl/tk interface? Specially, a way to patch from a web page (?)... By the way, do you think Pd can handle dynamic instancing of audio patches without audio dropouts? What specific tricks could help with it? I know audio is interrupted when the DSP tree is rebuilt, but I don't know exactly whether this always happens and if there are some techniques to avoid it. I need a way to keep audio running while an user is adding or removing some audio-processing abstractions. -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] web patching
An easy solution is to detect the onset of a DSP graph change and stop the audio for few milliseconds, then activate it again. You can use messages to Pd to do this, such as: How exactly would that prevent an audio dropout ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] web patching
If you deactivate and activate again with the right timing, the interruption is not perceivable. Used it in few patches sometimes. Work well. Please, check the link to the other thread I posted, there are further info. Discussions on this date back to 2005... M On Sat, Mar 3, 2012 at 11:42 AM, matteo sisti sette matteosistise...@gmail.com wrote: An easy solution is to detect the onset of a DSP graph change and stop the audio for few milliseconds, then activate it again. You can use messages to Pd to do this, such as: How exactly would that prevent an audio dropout -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. ACE, Sound Design MSc by Research (ongoing) The University of Edinburgh, UK ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com | http://www.thesaddj.com | http://www.flxer.net Director: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] program for osc-rate testing?
Hi, I wanted to test the rate/stability of the osc packages I am sending from Pd (around 3 packages every 40 ms) with another program outside Pd. Does anyone have any good sugestions for a programm (or even console utility) that can display the timings between the messages received on the port I'm sending to? I'm using XP and ubuntu (I guess the later one is more suited for this). I was also thinking of creating a control tester like a Pd patch that saves a click to an audio file every time a message is received. But that would still be inside Pd, so I don't know how precise it would be. Best, João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
Hi Hans On Fri, 2012-03-02 at 08:55 -0800, Hans-Christoph Steiner wrote: I'm happy to see you working on this. Since you are making a new version, perhaps it makes sense to change the names. Like maybe it makes sense to change the object from [arduino] to [firmata]? That's something I thought about doing in the past. This would also make it easier for testers going forward because they could keep the old Pduino installed and also use your new library. I suppose then the library would be called something besides Pduino too. But if you want to keep those names, that's fine by me. Actually, I prefer not to host a separate version/fork. I think the design of the protocol and its implementation in [arduino] is solid and I haven't messed at all with it. Our efforts for [arduino] were mainly focused on smallish issues with usability and portability. Our plans are to eventually push it into Debian as pd-arduino. For that goal, some changes like getting rid of name-spaced objects (for instance: [zexy/makesymbol], doesn't work in Debian with pd-zexy) and some other stuff were necessary. Plus, it got a bug fixed Ingo discovered a while ago. Still, the overall changes to [arduino] itself are rather smallish and I wouldn't expect any severe bugs. Also, I think we tested it quite well. The main effort, however, went into documentation and [arduino-gui] and to figure out the tiny details and differences between the several Firmata versions around in order to make the help-patch consistent as documentation and [arduino-gui] consistent in its behaviour. I consider the updated help-patch a significant improvement (in that it covers all features of the firmware, is clear in which pin supports which mode, explains the differences in different firmware versions) and I wouldn't see a reason to keep to old one living. Personally, I'd much prefer not to host a separate fork and I am all for joining forces, not separating them. With your consent, I'd like to push the new version to the svn repository. We could wait to do so, until we got some positive reports from a few people, of course. There is really no hurry. Also, I'd take responsibility for any issues and bugs related to Pduino (if that is what you want; I don't plan any 'hostile take-over'). Finally, if we eventually agree on merging our git Pduino with the official pd-svn/externals/hardware/arduino, I'd like to bump the Pduino version to the Firmata version. As I understand, [arduino] is a plain implementation of the Firmata protocol, not less, not more. I think it would make sense to reflect the version of the protocol it implements in its own version. We could still add a bug-fix number, so changes to [arduino] without switching the prococol version could be reflected. Something like 2.3.1 | | | | | Pduino bugfix version | protocol minor version protocol major version What do you think? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] program for osc-rate testing?
On Sat, 2012-03-03 at 13:49 +0100, João Pais wrote: Hi, I wanted to test the rate/stability of the osc packages I am sending from Pd (around 3 packages every 40 ms) with another program outside Pd. Does anyone have any good sugestions for a programm (or even console utility) that can display the timings between the messages received on the port I'm sending to? I'm using XP and ubuntu (I guess the later one is more suited for this). I was also thinking of creating a control tester like a Pd patch that saves a click to an audio file every time a message is received. But that would still be inside Pd, so I don't know how precise it would be. Do you assume it to be less precise in Pd? You could have a separate instance of Pd for the testing suite, then it wouldn't be 'still inside Pd'. Also, recording a click on each received message to a sound file would definitely be possible, but wouldn't it be a bit cumbersome to read it out? Wouldn't it be more feasible to write timestamps taken with [timer] or [realtime] to a text file with [textfile]? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] program for osc-rate testing?
I wanted to test the rate/stability of the osc packages I am sending from Pd (around 3 packages every 40 ms) with another program outside Pd. Does anyone have any good sugestions for a programm (or even console utility) that can display the timings between the messages received on the port I'm sending to? I'm using XP and ubuntu (I guess the later one is more suited for this). I was also thinking of creating a control tester like a Pd patch that saves a click to an audio file every time a message is received. But that would still be inside Pd, so I don't know how precise it would be. Do you assume it to be less precise in Pd? You could have a separate instance of Pd for the testing suite, then it wouldn't be 'still inside Pd'. Also, recording a click on each received message to a sound file would definitely be possible, but wouldn't it be a bit cumbersome to read it out? Wouldn't it be more feasible to write timestamps taken with [timer] or [realtime] to a text file with [textfile]? I already used 2 methods inside Pd to test the stability of the osc instructions going out from the patch: - by measuring the time with [realtime] into a textfile: it gave me values between 25ms and 65ms, where they should always be at 40ms (there's a [metro] sending the events) - in a separate pd patch receiving the osc flux, making those instructons record a [vline~] ramp in an audio file: All events are stable at 40ms, except every ~1,5s (at unregular paces) there's one event that delays itself by 10ms, catching up in the next event (like ...-40-40-30-50-40-40-...) So, I already used Pd to try to measure this, and got 2 different results. That's why I'm looking for a more imparcial measuring technique, located on the receiver side (I guess 40ms isn't that heavy for a osc rate). Having a different Pd patch on the side (being the same instance or not), is still inside Pd. E.g. I don't know if the irregularities in the click log I recorded come from the events themselves, or from [vline~] adjusting to the audio blocks (a problem similar to the one I mentioned some weeks ago in another thread). The help file says The [realtime] object is as much like your own wrist watch as Pd can possibly manage. It measures time according to your operating system's internal clock. Looking at the results I had (and even by using the 3 s count in the help patch) I don't know how much I can trust [realtime]. João ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] openstomp ... PD pedal?
http://rowebots.com/products. If you can get that OS to multiprocess then I reckon microchip would be one option I think better than Parralax. I havent kept up with the scene but around 7 years ago this http://geocities.ws/billy_stiltner/worldrecordplane/worldrecordplane.htmllittle chip only had 16 bytes of ram, 256bytes of code, ran at 1MHz and done 2chn PCM decoding and 2chn PWM output. Parralax was using Microchip PICS for there chips and putting it in a fancy learning package. Looks like Microchip has the 80MHz procs. You can write programs in RISC or even in C. I wold imagine the port of PD would be a nobrainer almost. Atmel is another microcontroller that would possibly make a nice little PD stompbox brain. What form of an embeddable host are you likely to find BSD in these days? I would look there first then shop around for something along those lines. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-02-27 à 10:34:00, IOhannes m zmoelnig a écrit : On 2012-02-26 19:50, Mathieu Bouchard wrote: Or else just discontinuing the MSVC edition... no. Why do you need to keep a MSVC edition, again ? You probably told me already, but I don't remember. Are there libraries that people use with GEM that require MSVC and can't work with MinGW ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-03-02 à 13:32:00, katja a écrit : How about function call overhead? For constructor and destructor no problem of course, but accessor wrappers will be called often, in fact it doubles the number of function calls for external access. Constant calls are possibly a lot quicker than variable calls. Pd does call by function pointer, which needs to be figured out before the CPU pipeline can start reading and parsing the machine-code for it. When it's just a function-pointer in a known variable, it's not very slow, and might be very fast (?), but it takes a lot more time if there are conditional statements necessary to figure out which function-pointer should be used. This should tell you a lot about Pd's message-passing if you read that part of Pd. A wrapper that is specific to each method is very fast, because the pointer is already known. GridFlow uses two levels of wrappers, one of which is supposed to be slow according to what I say above (because the outer wrapper does its own message dispatch) ; but keeping things in perspective, it's still faster than anything else in Pd, when it comes to doing things that no other Pd class provides. GEM's wrappers have virtually no runtime overhead, except that wrapper has to be written. GridFlow's method-wrappers are auto-generated, so that you don't have to write them. Those are two big examples of wrapping a C++ library in C so that it can be used in Pd. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
Le 2012-03-03 à 10:32:00, katja a écrit : I fail to see how those C wrappers could be inlined. Wouldn't that undo their raison d'être (replacing a C++ call with a C call)? But indeed function call overhead is small when compared to number-crunching, if these calls are done per block and not per sample. If a function is only called from a single location and the function is hidden, then the original function may disappear and become embedded into the wrapper. I don't see GEM hiding its classes in such a manner. What might happen instead, is that a lot of code gets duplicated into the wrapper. This makes the executable bigger, but you still get the extra speed from inlining that way (for small functions). The « omit frame pointer » optimisation may cut a lot of the overhead while reducing code size, for function calls that are not inlined. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Gem/Gridflow with PdDriod Party ...possible?
Le 2012-03-01 à 12:23:00, ALAN BROOKER a écrit : I've been playing around with the very excellent PdDriod Party and I was thinking if there was a way to have visuals incorpertated into the patchs with Gem/Gridflow? I am may tryout impeding libpd into a processing andriod sketch but wanted to just enquire about Gem/Gridflow :] When I started trying to port GridFlow to Android in 2010, I quickly hit a wall, but I did not try for long. Now I have a lot more knowledge of Android, so I might have better luck, or not ; but I'm not currently planning a port to Android, though if someone wants to try it, I could help a bit. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] C++ for reusable dsp lib - or better use C?
On Sat, Mar 3, 2012 at 6:40 PM, Mathieu Bouchard ma...@artengine.ca wrote: Le 2012-03-03 à 10:32:00, katja a écrit : If a function is only called from a single location and the function is hidden, then the original function may disappear and become embedded into the wrapper. Now I'm getting the picture. The original accessor functions (class members) should be defined inline so they get inlined in their C wrapper. Those class members must be defined in the header then, in the class body, as the wrappers may be in another file. What might happen instead, is that a lot of code gets duplicated into the wrapper. This makes the executable bigger, but you still get the extra speed from inlining that way (for small functions). I was thinking about simple getters and setters for single values and for passing array pointers. Code duplication wouldn't be a problem in that case. Thanks. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit : On 2012-02-27 18:22, Jonathan Wilkes wrote: Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing class-wide data-- like this: you mean something like [1]? [1] https://sourceforge.net/tracker/?func=detailaid=1403917group_id=55736atid=478072 It's related, but the need is for something that doesn't depend on the way it's written : if [import shadok] then [shadok/gibi] and [gibi] might be the same, but will use different receive-symbols. But more importantly, what you suggest is for accessing all canvas-objects that are of a same abstraction-class, which is not the same as sharing various properties that belong to a certain abstraction-class. I mean that the canvas-object used to make an abstraction-object is not the same as the abstraction-object itself. The canvas-object does not directly handle stuff that is implemented in pd, and its receive-symbols are really about canvas-responsibilities. So if an abstraction pretends to be a canvas using [receive] in an attempt to extend the list of methods that the object supports, then every message not meant for the canvas will cause « canvas: no such method ». An abstraction-object's canvas object, even though it represents the object itself, usually shouldn't be talked to directly from outside, as the abstraction-class is what is supposed to know whether and how 'vis', 'coords', etc., should be used. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Music Notation in linux
Le 2012-02-28 à 11:42:00, Lorenzo Sutton a écrit : I think this can be mitigated by using some gui programme which can then export to lilypond. It does add an additional passage to the chain but can be useful for editing the music. E.g. I have used Rosegarden (which is mainly a sequencer and has the advantage of playing the music). Is there any programme that can play a .ly file, using some reasonable expectations of what « staccato » means, et cætera ? __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [OT] Music Notation in linux
On 03/03/12 22:18, Mathieu Bouchard wrote: Le 2012-02-28 à 11:42:00, Lorenzo Sutton a écrit : I think this can be mitigated by using some gui programme which can then export to lilypond. It does add an additional passage to the chain but can be useful for editing the music. E.g. I have used Rosegarden (which is mainly a sequencer and has the advantage of playing the music). Is there any programme that can play a .ly file, using some reasonable expectations of what « staccato » means, et cætera ? You can create a midi output, with all the drawbacks and benefits. As far as I know there is no lilypond player, but to be totally honest I'm not sure it would make so much sense as lilypond is primarily a music typesetting language. The cited Rosegarden (but I'm sure other notation software too) has an Interpret function which will try to do what you describe for the 'standard' dynamics and articulation Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] save search path 0.43 OSX
- Original Message - From: Mathieu Bouchard ma...@artengine.ca To: IOhannes m zmoelnig zmoel...@iem.at Cc: pd-list pd-list@iem.at Sent: Saturday, March 3, 2012 3:36 PM Subject: Re: [PD] save search path 0.43 OSX Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit : On 2012-02-27 18:22, Jonathan Wilkes wrote: Sorry for the obscure example, but I think it's important for abstractions to have some way of accessing class-wide data-- like this: you mean something like [1]? [1] https://sourceforge.net/tracker/?func=detailaid=1403917group_id=55736atid=478072 It's related, but the need is for something that doesn't depend on the way it's written : if [import shadok] then [shadok/gibi] and [gibi] might be the same, but will use different receive-symbols. But more importantly, what you suggest is for accessing all canvas-objects that are of a same abstraction-class, which is not the same as sharing various properties that belong to a certain abstraction-class. I think I have a different solution which doesn't need an echo method for canvases. To send globally to _this_ abstraction, just concatenate the directory it lives in with the filename. To send to all instances on the parent canvas, just send to the above prefixed with the parent $0. To send to all instances anywhere up to the toplevel, just send to toplevel $0 plus dir plus filename. However, if you are in the parent patch and you want to send to all the abstractions that are children of the parent patch (non-locally), pd-foo/bar.pd seems like the only way to do that. I mean that the canvas-object used to make an abstraction-object is not the same as the abstraction-object itself. The canvas-object does not directly handle stuff that is implemented in pd, and its receive-symbols are really about canvas-responsibilities. So if an abstraction pretends to be a canvas using [receive] in an attempt to extend the list of methods that the object supports, then every message not meant for the canvas will cause « canvas: no such method ». Right, that's what the echo method is about. An abstraction-object's canvas object, even though it represents the object itself, usually shouldn't be talked to directly from outside, as the abstraction-class is what is supposed to know whether and how 'vis', 'coords', etc., should be used. My alternative method outlined above avoids this. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC ___ 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] choosing your language at launch WAS: Japanese Pure Data book is out now.
morning all, apologies for missing this the first time around, and for reviving the topic if the question has already been addressed, but... On 2012-02-25 17:59, András Murányi wrote: If you want the *whole* app to change language, I'm pretty sure it will need to be restarted. Then I guess an equivalent of export LANG can be issued from tcl (and/or C?) at startup. (Could someone with the knowledge confirm/correct this plz?) you can use the [locale] object (probable moocow/locale in pd-extended) to set C99 locale stuff like LANG (or more POSIXly correct, LC_ALL). Use it like: [set LC_ALL de_DE.UTF-8, set LC_NUMERIC C( | [locale] ... note that it's important to keep LC_NUMERIC=C in order to avoid parse errors for locales with funny floating-point conventions (such as de_DE, which uses the comma as a floating-point separator). The C equivalent is just: #include locale.h setlocale(LC_ALL,de_DE.UTF-8); setlocale(LC_NUMERIC,C); Not sure if this helps with changing the gettext-lookups for the running process though; maybe follow it up with an exec() ? marmosets, Bryan -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] choosing your language at launch WAS: Japanese Pure Data book is out now.
On 2012-02-24 23:11, Mathieu Bouchard wrote: Just setting the 2-letter language code is usually wrong, because most people want to also have the country code and encoding as well. For example : export LANG=fr_CA.utf8 selects French, Canada and Unicode UTF-8 all at once. ... unless you've done something like export LC_CTYPE=en_US.ISO-8859-1 or export LC_ALL=C when no one was looking ;-) marmosets, Bryan -- Bryan Jurish There is *always* one more bug. moocow.bov...@gmail.com -Lubarsky's Law of Cybernetic Entomology ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] choosing your language at launch WAS: Japanese Pure Data book is out now.
Glad it worked out. About handling the translations, I don't really have a good sense of who will want to use it in their native language and who in English. My guess is that the more technical people will be using Pd in English, and the less technical would use Pd in their native language. Based on that guess, then the idea would be to make it use the translations by default, then provide instructions for the more technical people to switch to English. You just demonstrated a simple yet effective way to force Pd in English on any system: remove the translation files in the po/ folder, i.e. ja.msg, etc. .hc On Mar 3, 2012, at 12:42 AM, Seiichiro MATSUMURA wrote: Hi Hans, Sorry, I misread your instruction. It was for how to make ja.msg file from ja.po file then to import it to Pd-extended0.43.app downloaded from nightly build. (I thought I needed to build app by myself.) Now, I can run Pd-extended0.43.1.app with Japanese UI. (see attached pic.) This is amazing! I can do fully checking. BTW, this is just a suggestion about language mode. If it is difficult to put language select pull-down menu in preferences, how is about not including all the language files in po folder of Pd-extended.app as default? It means the default language is English and installing the other language ~.msg files are optional. Users can download the language ~.msg file and put it in Pd-extended.app/Contents/resources/po folder under the instruction as they want it. It is not difficult even for non-geek people. This is like OpenOffice language plug-in files style. How do you think? Best, Sei Matsumura --- s...@low-tech-ism.com --- 2012年3月2日9:48 Seiichiro MATSUMURA s...@low-tech-ism.com: Thank you for the precise instruction. I could trace this but could not make Pd-extended0.43.app in the end. I can run pd unix file in pd-extended/src folder and see ja.msg is working partly, not all functions are working correctly like Bang button object is missing, Vslider is missing, etc. I need to check all the Japanese translated menu and indication in all the properties windows. Do I have to do any other steps for building Pd-extended0.43.app? I already check INSTALL.txt in pd-extended folder and this article but could not accomplish it. http://puredata.info/docs/developer/BuildingPdExtended Best, Sei Matsumura --- s...@low-tech-ism.com --- 2012年2月25日6:56 Hans-Christoph Steiner h...@at.or.at: I was updating pd-extended.git, so I threw in the new Japanese translation :-). I'll be sure to update it one last time before the final release, so you can test it in a real build. I'm all for choice with the language of the app, but it seems to me that is something that the OS should handle. So anyone who set their system language to English will get Pd-extended in English. For those who want some mix of languages, then there is no standard technique that I know of, and how you do it varies on each OS. If someone wants to code this for Pd-extended, patches are welcome. For the geeks, you can select the language easily when launching Pd from the terminal. This is what I do for testing the language support: $ export LANG=en $ /usr/bin/pd-extended or on Mac OS X: $ /Applications/Pd-extended/Contents/Resources/bin/pd You can see the supported languages in the po/ folder inside Pd. .hc On 02/23/2012 11:54 PM, Seiichiro MATSUMURA wrote: Thanks. I finished Transifex work in Japanese 100%. Then I was surprised my partly inputs of Transifex in middle of Feb. is already reflected in 0.43.1-beta 20120223. However, it seems working automatic depends on system language of OSX, now. I think it would be nice if users can select language mode in Preferences, for example like Audacity's language setting. Because many Japanese users (especially geeks) already get used to the general English menu and interfaces. Of course, Japanese interfaces is truly helpful for Japanese Pd newbies. So languages selectable is the ideal. Cheers, Sei Matsumura -- __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ Seiichiro Matsumura s...@low-tech-ism.com http://low-tech-ism.com/ __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/ 2012/2/22 Hans-Christoph Steiner h...@at.or.at: That's great! I wish I could read it. I love the idea of including the interviews and the PdCon report, it shows the multidimensionality of Pd. Its not just software, but the community behind it as well. To match this release, I think it would be nice to also have a complete Japanese translation of the Pd interface. To contribute, create an account on transifex and edit the Japanese translation in this webform: https://www.transifex.net/projects/p/puredata/resource/templatepot/ .hc On Feb 20, 2012, at 3:38 AM, Seiichiro MATSUMURA wrote: Dear list, The world first Japanese Pure Data book for sound programming will be published from BNN(Bug News
Re: [PD] Pduino: Call for testing
It won't really be a fork since I plan on making one more release, then I'm unlikely to touch the code again. So really, your development will be the active development. I would prefer that you use a different name unless you are interested in providing strict compatibility with the current Pduino. Things like using namespace prefixes are one example of compatibility that it sounds like you are not interested in, for example. Pduino deliberately uses namespace prefixes because that's currently the only way to guarantee the correct object is being loaded. Using [declare -lib zexy] [makesymbol] does not currently guarantee that (tho it should). .hc On Mar 3, 2012, at 6:47 AM, Roman Haefeli wrote: Hi Hans On Fri, 2012-03-02 at 08:55 -0800, Hans-Christoph Steiner wrote: I'm happy to see you working on this. Since you are making a new version, perhaps it makes sense to change the names. Like maybe it makes sense to change the object from [arduino] to [firmata]? That's something I thought about doing in the past. This would also make it easier for testers going forward because they could keep the old Pduino installed and also use your new library. I suppose then the library would be called something besides Pduino too. But if you want to keep those names, that's fine by me. Actually, I prefer not to host a separate version/fork. I think the design of the protocol and its implementation in [arduino] is solid and I haven't messed at all with it. Our efforts for [arduino] were mainly focused on smallish issues with usability and portability. Our plans are to eventually push it into Debian as pd-arduino. For that goal, some changes like getting rid of name-spaced objects (for instance: [zexy/makesymbol], doesn't work in Debian with pd-zexy) and some other stuff were necessary. Plus, it got a bug fixed Ingo discovered a while ago. Still, the overall changes to [arduino] itself are rather smallish and I wouldn't expect any severe bugs. Also, I think we tested it quite well. The main effort, however, went into documentation and [arduino-gui] and to figure out the tiny details and differences between the several Firmata versions around in order to make the help-patch consistent as documentation and [arduino-gui] consistent in its behaviour. I consider the updated help-patch a significant improvement (in that it covers all features of the firmware, is clear in which pin supports which mode, explains the differences in different firmware versions) and I wouldn't see a reason to keep to old one living. Personally, I'd much prefer not to host a separate fork and I am all for joining forces, not separating them. With your consent, I'd like to push the new version to the svn repository. We could wait to do so, until we got some positive reports from a few people, of course. There is really no hurry. Also, I'd take responsibility for any issues and bugs related to Pduino (if that is what you want; I don't plan any 'hostile take-over'). Finally, if we eventually agree on merging our git Pduino with the official pd-svn/externals/hardware/arduino, I'd like to bump the Pduino version to the Firmata version. As I understand, [arduino] is a plain implementation of the Firmata protocol, not less, not more. I think it would make sense to reflect the version of the protocol it implements in its own version. We could still add a bug-fix number, so changes to [arduino] without switching the prococol version could be reflected. Something like 2.3.1 | | | | | Pduino bugfix version | protocol minor version protocol major version What do you think? Roman [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity. -John Gilmore ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
