Re: [PD] SOLVED!!! Re: pitch to voltage SOLVED!!!
That works very well. Good job and thanks for sharing! One minor thing jumped to my eye: Your patch uses some instances of [fexpr~] and all of them actually don't need [fexpr~] functionality. I experienced that [fexpr~] is quite expensive, which seems apparent considering it is designed for feedback algorithms. I don't know if [fexpr~] is also expensive when you use it not for feedbacks as your patch does. Anyway, you could replace them by likely less expensive [expr~] instances: [fexpr~ $x1=0] - [expr~ $v1=0] Roman On Mon, 2014-04-28 at 00:59 +0200, simon wrote: hey miller and list, find attached a version that works beautifully. it's a dirty hack without upsampling but it works extremly well. don't ask me why, i have no idea. thanks for all the help miller, really appreciate it! and thanks for pd in general :-) cheers, simon On Apr 27, 2014, at 8:59 PM, Simon Iten wrote: sorry this one went off-list :-) On 27 Apr 2014, at 19:05, simon itensi...@gmail.com wrote: sure, here is the version with biquad in a subpatch with a block opject to upsample. probably i'm doing something wrong, i just copied from the block help-patch. sinetosawtoothupsample.pd On Apr 27, 2014, at 5:48 PM, Miller Puckette wrote: Drat, I don't have any explanation for this... can you send me the patch again? cheers M On Sun, Apr 27, 2014 at 05:44:22PM +0200, simon wrote: hmm, changing change to biquad does also not work. i mean it does as long as i don't upsample in the subpatch. as soon as i change the block object i get square instead of pulses... On Apr 27, 2014, at 3:48 PM, Miller Puckette wrote: Actually I don't know where the change~ object is from - I've nver seen t before. I would just use biquad~ 0 0 1 -1 0 (assuming that change~ simply ubtracts the previous sample from teh current one as I guessed from the patch :) M On Sun, Apr 27, 2014 at 03:40:01PM +0200, Simon Iten wrote: ok tried to upsample the whole thing (after the osc~) and now change~ does nothing anymore… it just spits out the same square wave i feed in…clues? On 27 Apr 2014, at 13:05, Simon Iten itensi...@gmail.com wrote: crosspost! sorry about the noise. thanks for the inputs i will try to to this. not sure if i can. otherwise i will ask back if that’s ok! On 27 Apr 2014, at 13:03, Simon Iten itensi...@gmail.com wrote: so if i would measure at the peak of the sawtooth and would upsample inside the pd patch, i would get higher resolution, right? any ideas how i can measure at the peak? (using the rpole output on both samphold inputs does not work and delaying one of them is also not working) which i would highly recommend you try this method with your gk-3 equipped guitar (one for each string) since you only have to cover a two octave range per string the error is tolerable. (you can add an offset to make it fit) On 27 Apr 2014, at 12:56, Miller Puckette m...@ucsd.edu wrote: That is an excellent, witty way to measure pulse withs using only tilde obects - my hat's off to you. The methond only has limited accuracy since its measurement is in samples. For instance, a 1/2 cycle of a 440-hz. tone at 44.1 kHz is only 50 samples, so there's only 2% accuracy. That's about 1/3 of a half tone (30-ish cents) which would sound horribly out of tune. There's an alternative sine-to-sawtooth recipe described here: http://msp.ucsd.edu/Publications/icmc10.pdf This is the basis of my guitar processing patch, smeck, but should be more broadly useful. But it has its own limitations: the sawtooth you get out is wiggly if the input sn't a pure sinusoid. There's also the possibility of simply pitch tracking with sigmund~. Use a maximum frequency around 6000 and a maximum of 6 partals (default 50!) for best results. cheers M On Sun, Apr 27, 2014 at 11:27:33AM +0200, Simon Iten wrote: dear list, i have a strange problem with my “sinetosawtooth” patch. it is basically a version of the pitch to voltage conversion used in the old gr300 guitar synths from roland. i cut out all the clutter to make it easier to look at and understand. (cut out the adaptive filtering at the input since i use a sine wave for this example and not a guitar string) here is how it works (or should): -an input signal gets amplified by a large factor and clipped. this squares the input. -the square wave is converted to pulses. -the pulses from the rising of the square wave are used to set and reset an accumulating filter (rpole~) this results in a sawtooth wave that varies in amplitude depending on the frequency of the input. -a sample and hold samples the peak of the sawtooth and holds it until the next peak occurs. this, after a conversion gives us the input frequency. yeah!
Re: [PD] can [bp~] be obtained with biquad coefficients?
On Sam, 2014-04-12 at 03:45 -0300, Alexandre Torres Porres wrote: change the [fexpr~] to something like [fexpr~ $x[0] + ($f2 * $y[-1]) + ($f3 * $y[-2])] f*ck, I'll be damned, now my patch that implements [bp~] with [fexpr~] seems to work, it's attached. Thanks! That is great! I never really dug into that topic, but having it as a patch makes it more accessible I think, at least for me. Thanks for sharing. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Wed, 2014-04-02 at 22:05 -0300, Alexandre Torres Porres wrote: So, tried other things, and I see it won't be able to deal with messages including $0 like [qlist]. So the reason must be not related to [qlist] or [textfile], but the way Pd handles (or doesn't handle) $0 in messages. Yes. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Wed, 2014-04-02 at 19:00 -0300, Alexandre Torres Porres wrote: Although I assume I don't think I get the hassle it'd be to do that. I'm still struggling to see what could be so tricky to make $0 possible to work in messages, sorry :P The reason is most likely not the difficulty to implement it, but as I said: probably nobody wants to introduce inconsistencies. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Wed, 2014-04-02 at 20:49 -0300, Alexandre Torres Porres wrote: By the way, haven't been really able to make it work well with [textfile]. If you get a symbol with $0-symbol from a text file, you can't use it to work as an address for [send]. Miller proposed to use the new [text] class introduced in 0.45, not the old [textfile]. I haven't checked myself, but according to him this would solve all your trouble as it allows - if I understand correctly - to take literal $0 strings that get expanded only at reading time. (Is that what you meant, Miller?) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Don, 2014-04-03 at 16:13 -0300, 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? Wow, you keep beating that horse after its dead for quite a while by now. It is _not_at_all_ about technical difficulties (probably it is indeed difficult, I don't really know). It's about breaking consistency. Expanding arguments of the parent is different from expanding to elements of incoming messages. While I understand your frustration to some degree, I don't think this debate is going lead anywhere, simply because of that fact that I don't believe any dev will deliberately introduce inconsistencies just for the sake of convenience. And yes, I understand the convenience of $0 expanding to the canvas-local ID and yes, it would probably make patching simpler. I am very much with you in this respect. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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. 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) * 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
Re: [PD] [qlist] and locality
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. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Don, 2014-04-03 at 18:32 -0300, Alexandre Torres Porres wrote: Wow, you keep beating that horse after its dead for quite a while by now I don't think this debate is going lead anywhere please, cope with my lack of knowledge in computer science/languages jargons. I'm sorry. I sure will (though I don't feel I have in any way less of a lack of knowledge). Actually, I don't have any computer science background myself. All I'm doing is asking to learn more about it and get what you guys mean. I'm not debating, since I'm even stating I couldn't do it when I say I probably won't be able to grasp all the details and will just take the word for it... So relax, you keep misjudging before reading more carefully. I'm not looking for a debate, and I'm also saying I'm cool with Pd's workaround myself, so there's no personal frustration. As I said, I'm not even thinking about me as my concerns come from luring people into using Pd, while I'm already sold for it. Anyway, having said that, I'd appreciate if anyone could help me understand Pd's structure and developing issues. I think I can't answer that. For instance, I don't think I understand what inconsistencies mean in this context. I try to explain some more. The confusion probably comes from the fact, that a similar looking syntax is used for two relatively different things in Pd. A $1 in an object box is substituted by the first argument I give to the parent abstraction. If I create [myabs 0.3] and myabs contains an [f $1], the value of $1 actually is '0.3'. If I have a message box [bla $1( in the same abstraction [myabs], we actually don't know yet what the value of this $1 is. Only when we send message to [bla $1( we know what the value of $1. [1.7( | [bla $1( When I click the [1.7( message box, we know that the $1 in [bla $1( is going to be substituted by 1.7. So far, so good. We now have encountered two different $1s in the same abstraction. Once it got substituted by 0.3 and once by 1.7, although both are written $1. Confusing, isn't it? I know that is nothing new to you at all as you most likely have used dollar variables in both ways already. What I am trying to say is that a $1 in a message box [bla $1( is a different animal from a $1 in an object box [f $1]. Pd could have been designed to make this distinction more explicit. It could have used # variables for message boxes and $ variables for object boxes. Then we would be able to do both with message boxes, namely expanding to a parent's argument AND expanding to an element of the incoming message, depending on whether we use the # or the $ syntax. [1.7( | [bla #1( In our hypothetical Pd, #1 would be substituted by '1.7' as soon as we click the [1.7( message box (as does $1 in the real Pd). Clicking on [1.7( would output 'bla 1.7'. [1.7( | [bla $1( In our hypothetical Pd, $1 would hold the value of the first argument given to the parent abstraction [myabs 0.3], in our example '0.3'. Clicking the [1.7( message box would output a message 'bla 0.3'. However, there is no such thing in the real Pd (yet). In the real Pd, the $1 in the message box works totally differently from the $1 in the object box. The canvas local-ID unique to each instance of a .pd file (abstraction or patch) can be considered as an argument to that abstraction or patch. Thus it can easily be accessed by $0 in object boxes. When you propose that $0s in message boxes are substituted by the canvas-local ID, then you want the function of the dollar variables to be different depending on what number follows the dollar sign. You want $0 to access an argument given to the parent, but $1 to be substituted by the first element of the incoming message. That is where the inconsistency happens: Why should the function be different based on the value I put after the dollar sign? In our hypothetical Pd, this would be a non-issue. You wouldn't expect a #0 in message box to get substituted by the canvas-local ID. You would use $0 for that. In the real Pd, we unfortunately don't have direct access to the arguments of the parent from message boxes. When you ask Why can't a $0 in a message box be substituted by the canvas-local ID, then you also should ask Why isn't a $1 in message box substituted by the first argument given to the parent? The answer is that this is the way Pd is designed. I'd prefer our hypothetical Pd, if it would exist. However, switching from today's Pd to our hypothetical Pd would surely break compatibility, which makes its introduction a bit less likely. Finally, I don't see any other concise solution than our hypothetical Pd for the $0-in-message-boxes problem. I hope I didn't cause even more confusion. Roman 2014-04-03 17:03 GMT-03:00 Roman Haefeli reduz...@gmail.com: On Don, 2014-04-03 at 16:13 -0300, Alexandre Torres Porres wrote: thanks for explaining it all imagine trying to design something like
Re: [PD] [qlist] and locality
On Don, 2014-04-03 at 18:41 -0400, Jonathan Wilkes wrote: 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. 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. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
On Mon, 2014-03-31 at 18:54 -0300, Alexandre Torres Porres wrote: Hi there, I can't get messages from [qlist] to an object with $0. Is this really a problem? You can: [nbx\ | [t b f] | \ [pack $0 f] | [add 500 $1-bla $2] | [qlist] [r $0-bla] | [print] The thing is you have to expand $0 before you're putting the messages into qlist. BTW: You also cannot internally expand to the arguments ($1, $2, etc.) of the abstraction that contains the qlist. You'd have to use the same 'trick'. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [qlist] and locality
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. 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. 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
Re: [PD] Alternatives to arraycopy
Hehe, I also thought: Wow, I have to check out the new [tabrecord~]. For the record: Miller most likely meant [tabwrite~] instead of [tabrecord~]. (According to the difference between [tabread~] and [tabplay~], [tabrecord~] would be the more suitable name for [tabwrite~]) Roman On Mon, 2014-03-31 at 08:17 -0700, Jonathan Wilkes wrote: 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] patch wanted: loop station
On Thu, 2014-03-27 at 05:09 -0400, pured...@11h11.com wrote: Not sure exactly what is making the click / glitch in my patches. I think the fact that I bring down the jack buffer to 64 didn't help... but I cannot be sure. I am still looking the archive / search engine to find a loop station in pd, but so far I found only basic implementation (no sync, no quantize, no cross-fade). I don't know the loop station. Can you elaborate a bit how quantize and sync work on? I think I understand how quantization works with MIDI, but with audio? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino
On Mon, 2014-03-24 at 19:19 +0100, ro...@dds.nl wrote: i'm trying to use Pduino-0.5 and/or pduino-master (from reduzent) with Windows 7 and Arduino Uno. i don't get anything with [info( or [firmware( or [version(. it's possible to pulse all outputs, i.e. it's visible on Led13. toggling Led13 in Pduino only gives a short flash on the Led. the GUI in pduino-master seems to do nothing, except connecting through [comport] what am i missing? Pduino assumes there is the Firmata firmware installed on the Arduino board. I _think_ many recent Arduinos come with the Firmata firmware pre-installed. If that is not the case, you can install it yourself with the Arduino IDE. If [firmware( returns nothing, I would guess there is no Firmata installed. If you are sure Firmata is installed, please give us more details: * Version of Firmata ? * Board model? * Pd distro / version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Compiling zexy in Udoo
On Mon, 2014-03-24 at 11:38 +0200, Alexandros Drymonitis wrote: On Mon, Mar 24, 2014 at 11:26 AM, IOhannes m zmoelnig zmoel...@iem.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-03-24 10:13, IOhannes m zmoelnig wrote: On 2014-03-23 11:07, Alexandros Drymonitis wrote: What am I missing here? either do: [...] or simple do # apt-get install pd-zexy That worked, thanks! Can I do the same for other libraries, like iemmatrix? The package is called pd-iemmatrix. Run this to get a list of available pd libraries: $ aptitude search ^pd- Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi 20140319 release candidate
On Mon, 2014-03-24 at 09:51 -0400, Ivica Ico Bukvic wrote: [...] At the same time, I also don't want to create extra work for you or anyone else, so to cut my monologue short, if you and/or the community so desire, I will stop posting any further announcements on any pd list, so as not to annoy you (and possibly others). I don't feel disturbed at all and I'm interested to get notifications like this in the future. Pd-l2ork announcements certainly belong here (why wouldn't they? Pd vanilla and Pd-extended is also discussed here). Though while not being him, I'm pretty sure IOhannes feels the same way. What you feel to be negativity is probably really only about technical aspects. Anyway, your post shows difficulties people might have by using the pd-announce mailing list and it's certainly a good thing to bring those problems up. Once there is clarity and agreement on the rules, it shouldn't be too difficult to successfully send announcements. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Application initialization failed: no display name and no $DISPLAY environment variable
On Sam, 2014-03-22 at 19:27 +0200, Alexandros Drymonitis wrote: Just installed Pd in my Udoo quad with sudo apt-get install puredata and all the necessary files appear to be where they should but when I type /usr/bin/puredata (or pd) I get the above message and then 'watchdog: signaling pd...' without anything else happening. Pd doesn't know where to display its GUI. I'm logging in udoo with ssh. What do I need to do? Depends on what you want. You can use X11 forwarding (ssh -X) in order to display Pd's windows on your local machine. Or you can run an X session on your Udoo and connect to your Udoo with VNC. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] mtx_*, mtx, mtx_-
On Wed, 2014-03-19 at 13:51 +, Pagano, Patrick wrote: can someone remind me where i locate these? iemmatrix. In Pd-extended, it might be necessary to [import hexloader] first before being able to create objects from classes with special chars like * or - (like [mtx_*] or [mtx_-]) Roman Patrick Pagano B.S, M.F.A Audio and Projection Design Faculty Digital Worlds Institute University of Florida, USA (352)294-2020 ___ 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 Mon, 2014-03-17 at 18:59 -0400, Jonathan Wilkes wrote: 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. It looks pretty good on Pd vanilla, too. Also, notice I've got hard-coded slider height = 128 in the algo. Still don't understand why math is done in vslider_bang. But that's how you did it? The code in your patch is based on the code from vslider_bang? I don't understand it at all, but it works :-) And you're asking, why go all through the trouble to get back the input value instead of just spitting out the input value? Not a clue (someone wanted to show off their math skills?) Hehe, look, I can do it this way, but look now, I can also do it this way .. hehe .. pretty cool, uuh? ;-) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Interface bug switching to edit mode with sub patches
On Mon, 2014-03-17 at 14:12 -0400, Jaime E Oliver wrote: Hi, In os x 10.8.5 with Pd 0.45-4, I'm just curious: Is the observed behavior specific to this new version or do older Pd's also exhibit this problem? when I save a patch that has a sub patch and this sub patch is open, the next time that I open it I have the following behavior: + Both the parent patch and sub patch are loaded, but the parent patch shows up in front. + Although the parent patch shows in front of the sub patch, I cannot switch from edit to run mode unless I close the sub patch behind it. It seems like the edit mode switch is being applied to the sub patch which is not the frontmost window and the correct behavior is that the frontmost window is being addressed by commands. I cannot test this in linux now, but I imagine some might. I tested with Pd 0.45-4 on Ubuntu 12.04 running fluxbox as window manager. The subpatch comes to front and when I switch to edit mode, I'm in edit mode of the subpatch. Does that indicate it is related to the OS / window manager? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] log function in slider
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... Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
On Sam, 2014-03-15 at 09:43 -0400, me.grimm wrote: I noticed though, is there a reason why it works on 0.45.3 and not 0.43.4-extended? Oh, yes. You're right. I got confused, because the equation to determine the current intra-step position for [vmetro] (now [rh_metro]) was assuming Hz and s, but most Pd classes expect ms. That is why I used a new feature introduced in 0.45 that lets you define your own timing unit for most timing related classes. I forget to reverse that when it finally worked. I worked some more on [rh_metro], fixed some bugs (re-entrency did cause Pd to hang) and put it on github.com. You'll find a slightly updated [rh_phasor~ ], which still uses [rh_metro] internally, here: https://github.com/reduzent/netpd2-patches Enjoy! Roman On Sun, Mar 9, 2014 at 5:39 PM, Roman Haefeli reduz...@gmail.com wrote: (I believe this might rather belong to pd-list instead of pd-dev) On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: Roman, wrapping points. The only drawback compared to [phasor~] is that the latter allows to control the frequency with a signal and the [metro]/[vline~] based phasor obviously doesn't. I never did quite figure it out but how do you do more advanced things with [vline~] such as updating/increasing ramp speed mid ramp? Frankly, I often find myself struggling with those kinds of problems. I'll be glad to help you build the [phasor~] replacement that has an additional bang outlet, if you need it. Are you saying this is possible with just metro/vline~ combo? I would be curious what that looks like if you did build it It wasn't as easy as I initially expected it to be. I already had a [metro]-like abstraction that can do intra-interval tempo changes. However, I figured it was buggy (it worked only for the first tempo change within an interval) and had to redo it. That was the most difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with extra bangs at each wrapping point wasn't as hard (at least not with its current limitations). Check attachment. Roman ___ 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
Re: [PD] log function in slider
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
Re: [PD] libpd and Unity
Hey On Mit, 2014-03-12 at 19:23 -0400, pured...@11h11.com wrote: [...] How is it there in the future? :-) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
On Mon, 2014-03-10 at 21:31 -0300, Alexandre Torres Porres wrote: What is the difference between using an abstraction or a compiled class? well, I assume they can be more efficient, but my only point here is what I said already and that you agree with - peak level should be available, seems like lots of trouble to need to make an abstraction for it. So, basically you are saying it is less trouble to make an external than an abstraction? The fact that neither I nor you made an external indicates otherwise. I know there's an external around, I give you an abstraction and you say you're still looking for the external? Why are abstractions second class citizens in your opinion? but I mean it deserves to be in vanilla. Agreed, but I still have difficulties in understanding why you desperately need it to be a compiled class (I am certainly not against it, though). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
On Sun, 2014-03-09 at 22:32 -0300, Alexandre Torres Porres wrote: Why not an abstraction in my point of view? Well, looks kinda cumbersome for that particular goal. I am with you in that I think it makes sense to extend [env~]. Regarding abstractions, I don't see what is cumbersome. What is the difference between using an abstraction or a compiled class? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On Mon, 2014-03-10 at 10:33 +0100, IOhannes m zmoelnig wrote: On 2014-03-09 14:15, Roman Haefeli wrote: k ... for me [packOSC] didn't work with [netsend], I didn't investigate why but just used [udpsend] instead. [netsend] is different from [udpsend] and [tcpsend] in that it sends incoming Pd (list/any) messages as FUDI. The latter two expect lists of bytes (list of numbers between 0 and 255). [packOSC] outputs OSC packets represented as lists of bytes and thus is designed to transported by either [udpsend] or [tcpsend], but not [netsend]. well, starting with Pd-0.45 [netsend] has support for binary data, which makes it compatible with [udpsend]. you have to pass it the -b switch though, so [udpsend] == [netsend -u -b] [tcpsend] == [netsend -b] Oh, good to know. Thanks for the update. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] KMI SoftStep foot controller?
On Son, 2014-03-09 at 22:52 +1100, Simon Wise wrote: On 09/03/14 02:58, Jonghyun Kim wrote: For OSC connection, you can also [netsend] with tcp, [netsend -u] with udp My experience was [netsend] is a little better than others. Ok ... for me [packOSC] didn't work with [netsend], I didn't investigate why but just used [udpsend] instead. [netsend] is different from [udpsend] and [tcpsend] in that it sends incoming Pd (list/any) messages as FUDI. The latter two expect lists of bytes (list of numbers between 0 and 255). [packOSC] outputs OSC packets represented as lists of bytes and thus is designed to transported by either [udpsend] or [tcpsend], but not [netsend]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
On Son, 2014-03-09 at 12:23 -0300, Alexandre Torres Porres wrote: As far as Vanilla goes it does seem like a great solution. Thanks a lot for that, seems to do the trick! But was really hoping for or even asking for a [peakenv~] like object. Why does it have to be an extra class and why not an abstraction? I consider abstractions more accessible as you can adapt them on the fly. Personally, I'd prefer abstractions (where the performance penalty isn't too huge). Yo, I attached an abstraction that extracts both, rms and peak level from the incoming signal. The peak output tries to emulate the behavior of VU meters of analogue mixing desks that have some kind of a fall back delay. Roman #N canvas 486 155 295 293 10; #X obj 17 12 inlet~; #N canvas 1064 100 194 249 peak_of_32 0; #X obj 14 70 f; #X obj 63 78 + 1; #X obj 14 44 t b a; #X obj 14 114 sel 0; #X obj 71 122 moses; #X obj 121 124 t a; #X obj 14 150 t b b; #X msg 118 146 0; #X obj 14 175 f; #X obj 14 197 outlet; #X obj 14 16 inlet; #X obj 14 92 mod 32; #X connect 0 0 11 0; #X connect 1 0 0 1; #X connect 2 0 0 0; #X connect 2 1 4 0; #X connect 3 0 6 0; #X connect 4 1 5 0; #X connect 4 1 8 1; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 6 1 7 0; #X connect 7 0 4 1; #X connect 8 0 9 0; #X connect 10 0 2 0; #X connect 11 0 1 0; #X connect 11 0 3 0; #X restore 93 77 pd peak_of_32; #X obj 93 120 rmstodb; #N canvas 1064 380 198 399 inertia 0; #X msg 96 111 0; #X obj 15 140 f; #X obj 55 141 + 1; #X obj 69 85 t a b; #X obj 15 248 f; #X obj 49 249 * 0.5; #X obj 15 12 inlet; #X obj 15 313 outlet; #X obj 15 37 t b a; #X obj 42 61 moses; #X obj 15 270 t a a; #X obj 139 196 t a; #X obj 15 175 t b a; #N canvas 590 409 162 222 magic 0; #X obj 26 17 inlet; #X obj 26 179 outlet; #X msg 26 112 1 \$1; #X obj 26 134 -; #X obj 26 158 max 0.9; #X obj 26 62 max 0; #X obj 26 41 - 15; #X obj 26 88 * 0.002; #X connect 0 0 6 0; #X connect 2 0 3 0; #X connect 3 0 4 0; #X connect 4 0 1 0; #X connect 5 0 7 0; #X connect 6 0 5 0; #X connect 7 0 2 0; #X restore 54 205 pd magic; #X connect 0 0 1 1; #X connect 1 0 2 0; #X connect 1 0 12 0; #X connect 2 0 1 1; #X connect 3 0 4 1; #X connect 3 1 0 0; #X connect 4 0 5 0; #X connect 4 0 10 0; #X connect 5 0 4 1; #X connect 6 0 8 0; #X connect 8 0 1 0; #X connect 8 1 9 0; #X connect 9 1 3 0; #X connect 10 0 7 0; #X connect 10 1 11 0; #X connect 11 0 9 1; #X connect 12 0 4 0; #X connect 12 1 13 0; #X connect 13 0 5 1; #X restore 93 98 pd inertia; #N canvas 603 218 325 344 peak_per_block 0; #X obj 204 15 table \$0.peak 64; #X obj 17 32 tabsend~ \$0.peak; #X obj 17 63 bang~; #X msg 49 139 64; #X obj 49 117 t b b; #X msg 89 148 0; #X obj 49 161 until; #X obj 49 184 f; #X obj 106 185 + 1; #X obj 49 206 tabread \$0.peak; #X obj 49 257 moses; #X obj 107 258 t a; #X obj 17 292 f; #X obj 49 231 abs; #X obj 17 87 t b b; #X obj 17 313 outlet; #X obj 17 10 inlet~; #X connect 2 0 14 0; #X connect 3 0 6 0; #X connect 4 0 3 0; #X connect 4 1 5 0; #X connect 5 0 7 1; #X connect 5 0 10 1; #X connect 6 0 7 0; #X connect 7 0 8 0; #X connect 7 0 9 0; #X connect 8 0 7 1; #X connect 9 0 13 0; #X connect 10 1 11 0; #X connect 10 1 12 1; #X connect 11 0 10 1; #X connect 12 0 15 0; #X connect 13 0 10 0; #X connect 14 0 12 0; #X connect 14 1 4 0; #X connect 16 0 1 0; #X restore 93 56 pd peak_per_block; #X obj 16 244 outlet; #X obj 16 84 - 100; #X obj 16 62 env~ 4096; #X obj 16 106 t b a; #X obj 93 142 - 100; #X obj 16 181 pack f f; #X obj 16 152 f; #X obj 16 128 del 0; #N canvas 690 175 211 142 NETPD 0; #X msg 9 15 version 0 1 0; #X restore 161 16 pd NETPD 2 0; #N canvas 154 288 158 285 overdrive 0; #X obj 15 43 1; #X obj 15 65 sel 1; #X msg 43 109 0; #X msg 15 100 1; #X obj 15 132 change; #X obj 15 154 sel 1 0; #X msg 75 176 64 64 64; #X msg 15 228 color \$1 -1; #X obj 15 202 netpd-rgb2iem; #X msg 15 176 200 0 0; #X obj 43 89 del 300; #X obj 15 16 inlet; #X obj 15 250 outlet; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 0 10 0; #X connect 2 0 4 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 9 0; #X connect 5 1 6 0; #X connect 6 0 8 0; #X connect 7 0 12 0; #X connect 8 0 7 0; #X connect 9 0 8 0; #X connect 10 0 2 0; #X connect 11 0 0 0; #X restore 171 163 pd overdrive; #X connect 0 0 4 0; #X connect 0 0 7 0; #X connect 1 0 3 0; #X connect 1 0 14 0; #X connect 2 0 9 0; #X connect 3 0 2 0; #X connect 4 0 1 0; #X connect 6 0 8 0; #X connect 7 0 6 0; #X connect 8 0 12 0; #X connect 8 1 11 1; #X connect 9 0 10 1; #X connect 10 0 5 0; #X connect 11 0 10 0; #X connect 12 0 11 0; #X connect 14 0 5 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Peak Level detect in Vanilla
On Son, 2014-03-09 at 14:05 -0700, Miller Puckette wrote: By the way - I just looked, and you can save a great deal of trouble using the array max object (new in Pd 0.25) You mean 0.45, I guess(?) - no need for 'until' horror. Oh, that is great! Thanks for the reminder, I haven't looked at [array] yet. But env~ seems incomplete to me if it's only going to compute RMS. Yeah, I see your and Alexandre's point: Why not extending [env~]? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Rewriting a unified phasor / metro object for reading tables
(I believe this might rather belong to pd-list instead of pd-dev) On Don, 2014-03-06 at 18:56 -0500, me.grimm wrote: Roman, wrapping points. The only drawback compared to [phasor~] is that the latter allows to control the frequency with a signal and the [metro]/[vline~] based phasor obviously doesn't. I never did quite figure it out but how do you do more advanced things with [vline~] such as updating/increasing ramp speed mid ramp? Frankly, I often find myself struggling with those kinds of problems. I'll be glad to help you build the [phasor~] replacement that has an additional bang outlet, if you need it. Are you saying this is possible with just metro/vline~ combo? I would be curious what that looks like if you did build it It wasn't as easy as I initially expected it to be. I already had a [metro]-like abstraction that can do intra-interval tempo changes. However, I figured it was buggy (it worked only for the first tempo change within an interval) and had to redo it. That was the most difficult part. Combining it with [vline~ ] to make a [vphasor~ ] with extra bangs at each wrapping point wasn't as hard (at least not with its current limitations). Check attachment. Roman vphasor~.tar.gz Description: application/compressed-tar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
On Thu, 2014-03-06 at 19:22 -0500, Brian Fay wrote: On Tue, Mar 4, 2014 at 8:53 PM, Chris McCormick ch...@mccormick.cx wrote: Not sure if this is relevant or already common knowledge but newer versions of Pd allow you to specify metro and delay tempo units, including in samples. e.g. [metro 500 1 samp]. Does anybody know if sample-accurate [metros] are available in libpd? Assuming, that libpd uses the same code for [metro], I'd say yes. I'm making an application that allows for fairly arbitrary divisions of a tempo. Originally I was going to make clocks out of metros, but I wasn't aware that you could set a [metro] faster than one bang per ms. [metro] used to have an artificial lower limit of 1ms. I assume this was implemented in order to save Pd from freezing if a [metro] accidentally received a '0' as interval. It seems that is not the case anymore in 0.45. The current behavior is that it allows any non-zero input, but falls back to one unit as defined in the 'tempo' method when set to 0. If I wanted a bunch of different rhythms, not just eigths and sixteenths, but triplets and divisions of fives or sevens or whatever, I would need to make a bunch of [metro] objects (or maybe one running at the least common multiple of the various divisions). In the end, I settled on handling this logic in the Java side of my application by counting samples and doing some math. This is still only sample precise, while you could make it sub-sample precise in Pd. This isn't addressed to you specifically, but it is a common misconception to think of the audio domain as being precise and the message domain as being rounded to vectors. This might apply to many softwares, especially those that have two configured rates, one audio sampling rate and one fixed control rate. However, there is no such thing as a control rate in Pd. It is true, though, that many classes with message inlets and signal outlets only evaluate the incoming message only at block boundaries ([tabplay~], [line~] and more). However, [vline~] is the __one__ class that connects the two worlds (message and signal) without losing precision. But I'm getting off-topic now, as your topic is about precision in the message domain only. Anyway, the precision of [metro], [delay], [timer] and co is only limited by the float type used in Pd. I can schedule bangs at arbitrary divisions of a base amount of time (so I can make seven-tuplets or fiftythree-uplets or whatever strange rhythm I want to). In theory my solution should be sample-accurate, and it sounds like it's working fine. But is there a straightforward way to do this in pd that I completely overlooked? It depends on what you consider straight-forward. It is certainly possible to have many [metro]s with arbitrary divisions running in sync. I still think the whole topic is very complex. I implemented something like that in some of the netpd instruments. However, I figured the tick rate of the master metro would be way too high, if I'd make it dividable by all the possible divisions I can think of. I went for a different strategy. The master metro ticks at 16th of the given BPM. I made an [metro] replacement abstraction that takes divisor and dividend as arguments. [polymetro 7 5] plays 7 ticks within the period of 5 ticks of the master metro. [polymetro] is designed so that it runs on its own and plays 7 ticks and then waits for every 5th master tick to start again. The difficult part was to allow tempo changes without losing sync. Pd's [metro] applies the new tempo only at the next tick. In order to be able to run many [polymetro]s concurrently without them losing sync on tempo changes, I had to create a [metro] replacement that allows for in-interval tempo changes. By using that [metro] replacement in the master metro and the [polymetro]s, it is possible to change tempo at any time without losing sync. One issue, that I haven't solved yet is a clean start at an arbitrary tick. [polymetro] doesn't immediately start when master metro is started at a non-zero tick, but it waits for the next sync tick of the master (any 5th master metro tick in the case of [polymetro 7 5]). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-dev] Rewriting a unified phasor / metro object for reading tables
On Wed, 2013-05-08 at 22:00 +0100, Ed Kelly wrote: Hi Lists(s), I'm rewriting phasor~ and unifying it with metro so that a pulse is generated from the boundaries of each ramp - so that bars of music can be read using tabread~ objects with a sample-accurate metro. I'm sure someone will say this can already be done, Yes! but it has to be dropped into the Ninja Jamm patch, so there isn't really time to rewrite the rest of the patch. Frankly, I am pretty sure, just using what Pd provides is too easy to use and likely less time consuming than writing your custom external. (Or I am totally missing the point of this adventure). I don't fully understand the way phasor~ wraps, but I have the object firing out bar numbers correctly. I'm putting clocks in for 16ths and 24ths of the beat, initiated on each wrap. I need to minimise CPU, so what I want to know is this: Does phasor~ always start from 0 and go to 1, i.e. is there always a signal value of 0 at the start of the ramp and a signal value of 1 at the end? As I write this, my common sense tells me it should be yes but I want to make sure. I suppose I should just try it really... No, it's not the case. A [phasor~] ramp virtually starts always at 0 and ends at 1 - true, but most of the time the wrapping point doesn't lie exactly on sample boundaries. This means the sample values around the wrapping point are almost never 1 or 0, respectively. Trying to derive precise timing from the audio domain is a moot exercise anyway, in my opinion. The best you can get from this approach is sample precision and analyzing all samples of a signal is relatively expensive. If you truly care about CPU consumption and a proper design from the start, use [metro] - which is as precise as 32-bit floats can be - and [vline~] - which actually uses the precise timing from [metro] (as opposed to [line~] that doesn't). With this combo [metro]/[vline~] you can rebuild [phasor~] with the additional benefit of giving you more-than-sample-exact bangs at the wrapping points. The only drawback compared to [phasor~] is that the latter allows to control the frequency with a signal and the [metro]/[vline~] based phasor obviously doesn't. I'll be glad to help you build the [phasor~] replacement that has an additional bang outlet, if you need it. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Egregore source / call for beta tester
Hey Cyrille On Don, 2014-02-27 at 12:39 +0100, Cyrille Henry wrote: Hello, Some of you have seen the egregore performance by chdh during the last pd convention, or during other occasion. http://www.chdh.net/egregore I've seen your performance in Weimar and I was deeply impressed. Though I expressed my excitement by clapping very loud, I somehow missed to tell you personally. Now, it's the moment... :-) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] easing in pd
On Thu, 2014-02-27 at 15:30 +0800, kickowang wrote: HI, Chun Lee with me made this abstract two years ago,you can try it. https://code.google.com/p/pd-tweener/ or https://github.com/aluanwang/pd-tweener That's a pretty neat library. Thanks for sharing! Roman ___ 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
On Tue, 2014-02-25 at 21:11 +0100, Pierre Massat wrote: Hi all, Thanks for your replies. I get the same error message in the console about JACK, regardless of whether I start it before Pd or not. The sound works though most of the time. This error indicates, that you didn't set the necessary permissions for real-time setup: JACKerror: Cannot use real-time scheduling (RR/55)(1: Operation not permitted Don't know, if this guide is still up-to-date, but I usually could make it work with it: https://help.ubuntu.com/community/UbuntuStudioPreparation#Real-Time_Support There is a package in the Ubuntu repos for pd-extended. It's called Pure Data with patches and a large collection of externals in the Ubuntu software Center. Software Center shows you everything that is currently installed. To know where you got your package from, do this in a terminal: $ apt-cache policy pd-extended If you only see a line like: 100 /var/lib/dpkg/status and no actual source line, this means you installed the package from a downloaded deb-archive. My Ubuntu is up to date (last update last week-end I believe). Could it be that it was fixed in 13.04 but not in the older LTS version ? Sorry, I was wrong about that, according to Cyrille. Roman ___ 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
On Wed, 2014-02-26 at 09:40 +0100, Pierre Massat wrote: Hi Roman, Good point about the permissions, i'll check that. I don't need to know where I installed pd-extended from (I'm too young to suffer from dementia). Good for you. I said it's there in the Ubuntu repos because this is where I got it (not from puredata.info or anywhere else, and certainly not from a manually downloaded archive). Depending on what packages you have installed and what entries you have in /etc/apt/sources.list or /etc/sources.list.d/ Ubuntu Software Center shows you different things. The fact 'pd-extended' appears in your Software Center doesn't mean the package 'pd-extended' originates from the official Ubuntu repositories. On my box, where I have enabled only all Ubuntu sources, I don't get any results when searching for 'pd-extended' in Software Center. Probably I'm totally off, but to me it still seems you got your 'pd-extended' from somewhere else. Roman ___ 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
On Wed, 2014-02-26 at 10:27 +0100, Pierre Massat wrote: I might have indeed added other sources, so Roman and IOhannes are probably right. Still, knowing that doesn't really solve my problems, does it ? I was suggesting this is related to your problems. You told us where you have your pd-extended from and I tried to explain that it is quite unlikely. That's all. I will try what Katja suggests regarding rt priorities. Hopefully that will fix the errors I get with JACK (problem one of 3). Are you sure, you don't suffer from dementia? It was me talking about rt permissions... (Sorry, I couldn't resist) :-) Regarding your other problems: - and Alsa throwing this error in the console : ALSA output error (restart failed): Broken pipe (though the sound does work). - X crashes sometimes when typing stuff in an object box, I find it strange this happens also on 12.04. I am using Pd (though not Pd-extended) regularly ___ 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
Sorry, that got sent prematurely. On Wed, 2014-02-26 at 11:33 +0100, Roman Haefeli wrote: Regarding your other problems: - and Alsa throwing this error in the console : ALSA output error (restart failed): Broken pipe (though the sound does work). I think I see this error from time to time, though I didn't worry about it. The one thing to know with Pd and ALSA on Ubuntu (12.04 or probably even other releases), is that Pd wants to have exclusive access to the sound card. So if you start Pd's DSP while some pulse audio client is using the soundcard, Pd is not able to connect to the soundcard. On the other hand, when Pd has DSP on and is connected to the soundcard, you cannot play sound from any pulse clients. So if you want Pd to be able to grab the soundcard, make sure you don't have any Youtube movie playing in Firefox. - X crashes sometimes when typing stuff in an object box, I find it strange this happens also on 12.04. I am using Pd (though not Pd-extended) regularly on 12.04 on machines with Intel drivers and never run into this kind of problems. Of course, this is anecdotal and doesn't mean they cannot happen. If there is still no fix for this bug available (I thought people had to compile Inter driver manually to get rid of the problem), I'd try to mitigate the problem by checking, if it happens also with Pd vanilla or Pd-l2ork. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] easing in pd
On Mit, 2014-02-26 at 20:42 +, David Schaffer 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... Those give you a smooth ramp between -1 and 1: [3.1415, 0 3000( | [line 0 20] | [cos] or: [-3, 3 3000( | [line 0 20] | [expr tanh($f1)} Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Mon, 2014-02-24 at 15:27 +0100, Ingo wrote: Roman, are you using MIDI in theory or real life? Frankly, I use (physical) MIDI quiet rarely and I'm far from hitting any of its limits as I mostly use some kind of MIDI controller. Jitter is MIDI's alias name. Yeah, I guess that is true. In practice MIDI data is being reduced as much as possible to avoid overloading the MIDI bus and in return causing serious timing problems or even missing data. Since I would not expect this signal to be the only one through the MIDI interface I would actually reduce the data on fast changes even drastically more. All (decent) MIDI receiving devices interpolate between the values in order to avoid zipper noise. Being even more nit-picking, I say interpolation doesn't address jitter, though I totally see what you mean. Being that precise doesn't actually matter that much. I see your point - in fact I had the same thought that you had at first! I dropped it right away. Working on a daily basis with MIDI I know that this is a waste of time. Waste of programming time or waste of CPU time? The latter doesn't really make a difference. Actually: I would add a [speedlim 5] to reduce data further and you still wouldn't hear anything unusual. I agree that those subtleties are hardly noticable. However, I felt the need to point out the differences between our approaches, as you removed what I considered crucial parts of the example. That reminds me a little of people asking for 14-bit pitchbend. It would take about 11 seconds to move the pitchbend wheel on a keyboard from the bottom to the top. Even a 7-bit pitchbend takes more that 80 ms sending all values. It's impossible to play music with a precise timing like this! In practice a very fast volume change going from 0 - 127 usually gets reduced to 3-5 numbers in order to allow additional controllers like pitchbend and aftertouch to be sent at the same time and still keep the note on jitter within a range of maybe 3-8 ms (plus the jitter of the interface itself). Sure, can't argue with that. You are assuming a scenario where this MIDI fader emulator is used to control real MIDI receivers. I was more thinking of a scenario where the emulator is used to substitute a real MIDI controller/sender. There is no precision loss within Pd, so why not use the precise implementation? And BTW - why would random need extra precision? Doesn't the word random say it all? No, the endpoints are supposed to be random, not the ramps in between. Another neglected thing is the curve that the data change should have. That would obviously require some extra calculation. I don't remember reading anything about that in the original posting, though. Me, neither, though in real that is certainly an issue. I don't know why I'm so pig-headed with precision. I guess the mere fact that Pd allows for such implementations makes me want to use them everywhere. I personally see beauty in this ability of Pd. Roman ___ 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
On Die, 2014-02-25 at 19:50 +0100, Pierre Massat wrote: 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 am pretty sure there is no package called 'pd-extended' in the Ubuntu repositories. Probably you got it from Hans' ppa or from apt.puredata.info? Also, is your Ubuntu 12.04 up-to-date? Your bug description sounds like an intel driver bug in 13.04 or 13.10 that has been discussed a lot on this list. I thought this bug has been fixed for quite a while. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Mon, 2014-02-24 at 13:35 +0100, Ingo wrote: Sorry, forgot ta add [change -1] after the [i]. I thought this was meant to be used with a MIDI signal - maybe I got that wrong? Yes, it is. I'm nit-picking here. The patch you posted before also works, even without the [change -1]. But even adding the [change -1] doesn't address the issues I mentioned. On a fast ramp, it still misses some values and it still suffers from jitter. It's only details I'm talking about here, yes, but since you decided to remove the features from my version, I hoped to be able to illustrate them with words. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Montag, 24. Februar 2014 10:34 An: pd-list@iem.at Betreff: Re: [PD] smooth random numbers On Sun, 2014-02-23 at 04:20 +0100, Ingo wrote: Starting from Roman's patch I would probably do it like the attached patch. Many ways might solve a certain problem and in Pd those many ways can often be divided into a subtractive approach - more than necessary is generated and the overhead is filtered out afterwards - and an additive approach - exactly the data needed is generated. I believe you totally missed the point why I chose the latter here. Using a constant time grain for [line] generates too much data for slow ramps, leading to many duplicates. Attach a print to our patch and you'll see. At the same time it misses some integer numbers for fast ramps. Also, by having a fixed time grain the result looks like a resampled ramp (which it basically is), which means it is jittery and doesn't emulate a steady movement of the fader. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On Sam, 2014-02-22 at 21:54 +, Pagano, Patrick wrote: I would like to start creating random midi values from 0-127 and pick each number say every 5 second and have each random number then flow to the next smoothly. so if say the first number is 60 and the second is 85, the data stream would flow from 60, 61, 62 63.until it reached 85 and then from 85 smoothly to the next random selection. See attached patch. I have not had the luck i was hoping with Vline, someone suggested an array but i am hoping someone might share some math or abstraction so i can get a handle on how to implement it Though one could do it with [vline~ ], it is probably cheaper (cpu-wise) and actually simpler with [line]. The trick is to adjust the time grain to make it output only integer numbers. Roman #N canvas 645 162 450 300 10; #X obj 71 231 line 0 1000; #X obj 71 55 random 128; #X obj 105 105 -; #X msg 105 158 5000 \$1; #X obj 105 180 /; #X obj 71 29 metro 5000; #X msg 71 206 \$1 5000; #X obj 71 4 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 105 127 abs; #X obj 71 77 t a a a a; #X obj 132 103 print next_target; #X floatatom 71 253 5 0 0 0 - - -, f 5; #X connect 0 0 11 0; #X connect 1 0 9 0; #X connect 2 0 8 0; #X connect 3 0 4 0; #X connect 4 0 0 2; #X connect 5 0 1 0; #X connect 6 0 0 0; #X connect 7 0 5 0; #X connect 8 0 3 0; #X connect 9 0 6 0; #X connect 9 1 2 1; #X connect 9 2 2 0; #X connect 9 3 10 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] new [list tosymbol] / [list fromsymbol]
Hey Miller This is a quantum leap for Pd. This extension to the [list] family opens a whole lot of new possibility. Thanks for including it into the upcoming Pure Data. And thanks to Chris McCormick who I believe provided the patch. As a native German speaker, I had to try it out with ä ö ü, of course. [list fromsymbol] gives me '-61 -92' for ä. Is there a reason it outputs signed numbers (-128 to 127) instead of the (supposedly more common) byte representation (0 to 255)? [list tosymbol] deals with both the same way. Both '-61 -92' and '195 164' return an 'ä'. Roman ___ 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 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. 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. Anyway, thanks for your thoughts. Roman ___ 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 Mon, 2014-01-27 at 21:34 -0500, Jonathan Wilkes wrote: On 01/27/2014 05:35 PM, Roman Haefeli wrote: 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). Interesting idea. That would presumably constrain the field variable's screen coordinates so that it doesn't move when you click-drag it. I'm not sure, if I fully understand the quanta syntax. I'd assumed that something like x(-30:30)(0:0) would not allow any movement, as you suggest. But it is still movable as if I'd use plain x (without quanta). When I use something like x(-30:30)(-1:1), it jumps between -30 and 30. Then use the same field variable for your [drawnumber]. Unfortunately, when using quanta, the variable doesn't return the input (my mouse movement), but the result. So the number jumps between -30 and 30 as well. Roman ___ 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 Die, 2014-01-28 at 12:40 +0100, João Pais wrote: there might be a complicated and confuse way of doing it - by clicking the scalar, you activate a click message to the drawing window, that clicks in the drawed number. For that you would have to look around the click messages in the pd documents, which I didn't really understood so far. Can you intercept mouse events done in the canvas? Can you even do it without externals? Roman 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 ___ 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 Mon, 2014-01-27 at 23:35 +0100, 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? To answer my own question: I had some thought about dealing with the 'capture the keyboard' part. When clicking the rectangle, I could use the pointer to route keyboards events from [keyname] to the clicked scalar. This way, I could even use 'Left' and 'Right' key events to move the scalar selection with the keyboard. This would allow to set a whole array of numbers by only using the keyboard. It's still not clear how to unselect the whole thing, when data entry is completed, though. I believe many interfaces allow de-select something by clicking anywhere nearby. Don't know if that is feasible in Pd. Using a key would be another option. The 'Escape' key, for instance. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Data structures and their clickable area
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? Similarly, I'd like to be able to mouse-drag anywhere in the rectangle in order to change the value of the number. Any ideas? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Comma in Textfile Vanilla Solution
On Sam, 2014-01-25 at 18:09 -0500, me.grimm wrote: I didnt realize this was a problem until i tried to read a textfile with a comma in it (yes escaped with a \) so hello\,world; gives me: hello\\,world now what? What would you rather expect to see within Pd? Non-escaped commas or single-escaped commas? What version of Pd is that? I made a small test with most recent 0.45 from git and my results are somewhat different, though still a bit messy: text-- \, comma at the beginning; comma\, right after first word; comma in\, the middle; comma at the end\,; /text--- gives: print-- print: , comma at the beginning print: comma, right after first word print: comma in\, the middle print: comma at the end\, /print-- While commas at the beginning or after the first word are displayed unescaped, all other commas are shown with escaping character. Is that a bug? Am I right in thinking it would be desirable if escaping characters wouldn't be displayed at all? It might be worth to note that feeding those lines to another [textfile] leads to a text file identical to the source which might indicate this is only a displaying issue. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Unescaped commas in Pd 0.45 files
Hi all Pd's file format has changed since 0.45 as a new feature was introduced that lets you set the width for all boxes and comments. The object width is saved in the patch by using an yet unused mechanism. Before, an ordinary message box was stored like this: #X msg 93 110 bla; Now since 0.45, when the width of the object has been manually altered, the line looks like this: #X msg 93 110 bla, f 35; This un-escaped comma does not comply with the FUDI protocol as used by many other object classes like [netsend]/[netreceive] or [textfile]. Before that change, Pd files could be treated as fully FUDI compliant. It was possible to use [textfile] to read and process Pd files. After saving, those files were still functional Pd files. Since the new feature, Pd files cannot be processed in the same manner. A message box as defined above results in: #X msg 93 110 bla; f 35; The resulting Pd file is corrupt and cannot be parsed by Pd anymore. I considered it a great advantage that the same protocol was used consistently throughout Pd. Though it might not have been an advertised feature, it made a lot of sense to me and I've been exploiting it. netpd now suffers from that new feature because it uses [textfile] to read and transfer patches between clients. Any patch that was made in Pd 0.45 and uses manually altered object widths breaks horribly when transferred. Miller suggested to use the newly introduced [text] object instead [1]. It allows to export a bunch of FUDI messages (or a Pd file, so to speak) as one single list. Regarding the problem above, that surprisingly even works for Pd files that use the new feature. The problem I face is that OSC packets have a maximum size and some Pd files are too large to fit into one OSC packet. I could split them up, but with lists there is no way to tell how many bytes they are using (you can only measure the number of atoms). I'm writing to the list to raise awareness of the issue. As 0.45 is still fresh, the new format may not be yet carved in stone. It might also be the case that I'm the only one who cares. Well, scrap it then. Roman [1] Check that out if you haven't already. It opens up a lot of new ways to deal with texts in Pd. I think it is an excellent new object! Thanks, Miller. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Unescaped commas in Pd 0.45 files
Oh, interesting. This works very well. Many thanks for the hint. I'm going to use that for now. I only figured now, that a construct like this is still parsed correctly by Pd: #X msg 93 110 bla, f 35, msg 93 130 blu, f 20; (This creates two messages boxes) I only understand now, that Pd makes a clear distinction between ';' and ',' when parsing patch files. [textfile] on the other hand seems to treat both the same. One bang outputs data until the next comma OR semicolon. So my statement that Pd files are not FUDI compliant in Pd 0.45 is somewhat unqualified. [netreceive] behaves similar to Pd's parser. It flushes only when it receives a semicolon, but not on a comma. However, if the flushed buffer contains unescaped commas, it is sent as several messages. One could argue that the correct behaviour of [textfile] should be similar: When banged, it should output everything until the next semicolon. If that data contains commas, it is sent as several messages. The lack of distinction by [textfile] is actually the source my initial problem. But if reading files with [textfile] would behave correctly, writing would still be an issue: How should [textfile] know wether to use ';' or ',' to terminate incoming lists? Roman On Son, 2014-01-26 at 09:05 -0800, Miller Puckette wrote: Well, perhaps this would be a workaround at least: you could catch lists strting with the symbol 'f' and prepend #X to them, thus: #X msg 93 110 bla; #X f 35; (But perhaps there's some reason you can't filter the messages... I don't know al lthe ins and outs of how netpd sends patches around :) M On Sun, Jan 26, 2014 at 01:14:23PM +0100, Roman Haefeli wrote: Hi all Pd's file format has changed since 0.45 as a new feature was introduced that lets you set the width for all boxes and comments. The object width is saved in the patch by using an yet unused mechanism. Before, an ordinary message box was stored like this: #X msg 93 110 bla; Now since 0.45, when the width of the object has been manually altered, the line looks like this: #X msg 93 110 bla, f 35; This un-escaped comma does not comply with the FUDI protocol as used by many other object classes like [netsend]/[netreceive] or [textfile]. Before that change, Pd files could be treated as fully FUDI compliant. It was possible to use [textfile] to read and process Pd files. After saving, those files were still functional Pd files. Since the new feature, Pd files cannot be processed in the same manner. A message box as defined above results in: #X msg 93 110 bla; f 35; The resulting Pd file is corrupt and cannot be parsed by Pd anymore. I considered it a great advantage that the same protocol was used consistently throughout Pd. Though it might not have been an advertised feature, it made a lot of sense to me and I've been exploiting it. netpd now suffers from that new feature because it uses [textfile] to read and transfer patches between clients. Any patch that was made in Pd 0.45 and uses manually altered object widths breaks horribly when transferred. Miller suggested to use the newly introduced [text] object instead [1]. It allows to export a bunch of FUDI messages (or a Pd file, so to speak) as one single list. Regarding the problem above, that surprisingly even works for Pd files that use the new feature. The problem I face is that OSC packets have a maximum size and some Pd files are too large to fit into one OSC packet. I could split them up, but with lists there is no way to tell how many bytes they are using (you can only measure the number of atoms). I'm writing to the list to raise awareness of the issue. As 0.45 is still fresh, the new format may not be yet carved in stone. It might also be the case that I'm the only one who cares. Well, scrap it then. Roman [1] Check that out if you haven't already. It opens up a lot of new ways to deal with texts in Pd. I think it is an excellent new object! Thanks, Miller. ___ 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] non linear distortion
On Fre, 2014-01-24 at 15:38 -0800, xiaoping lyu wrote: [...] tube amplifiers [...] are there any nonlinear distortions in pd? or do anybody have tried implementing something like this? signal strength | | [expr~ tanh($v1*$f2)] | Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] create list by header message
On Don, 2014-01-23 at 19:43 +0100, Peter P. wrote: Hi, this might be totally simple, but I am wondering what is the most elegant way of creating a list out of individual messages 12 23 34 45 meaning a list which holds four items, and which is always created at the number '12', and sent out at the nu,ner '45', yielding: list 12 23 34 45 so some kind of parallelization depending on a header value (12). Something like this? (see attachment) Roman #N canvas 43 101 385 424 10; #X msg 20 315; #X msg 20 107 12; #X msg 20 258 add2 \$1; #X obj 20 143 t a b; #X msg 47 167 1; #X obj 71 230 spigot 0; #X obj 20 81 sel 12 45; #X msg 129 122 45; #X obj 129 156 t b a b; #X msg 168 182 0; #X msg 129 261 bang \, set; #X obj 20 372 print; #X floatatom 20 23 5 0 0 0 - - -, f 5; #X msg 76 20 12 \, 23 \, 34 \, 45; #X connect 0 0 11 0; #X connect 1 0 3 0; #X connect 2 0 0 0; #X connect 3 0 2 0; #X connect 3 1 4 0; #X connect 4 0 5 1; #X connect 5 0 2 0; #X connect 6 0 1 0; #X connect 6 1 7 0; #X connect 6 2 5 0; #X connect 7 0 8 0; #X connect 8 0 10 0; #X connect 8 1 2 0; #X connect 8 2 9 0; #X connect 9 0 5 1; #X connect 10 0 0 0; #X connect 12 0 6 0; #X connect 13 0 6 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Compiling Pd in Sabayon
On Don, 2014-01-16 at 12:50 +0200, Alexandros Drymonitis wrote: Having had some problems with audio drop outs in Ubuntu, I am now giving Sabayon 14.01 a try. I'm trying to compile Pd, ./autogen.sh seemed to work fine, but when I type ./configure --enable-jack things go wrong. At the end of configure I get these messages: ./configure: line 15417: syntax error near unexpected token `JACK,' ./configure: line 15417: `PKG_CHECK_MODULES(JACK, jack, have_jack=yes, have_jack=no)' configure: error: ./configure failed for portaudio Actually, the configure that failed is the one for portaudio, not the one for Pd. I _believe_ it should be possible to compile and use Pd without portaudio. Pd's configure script has a flag --disable-portaudio, but it seems using it does not suppress the execution of portaudio's configure script (here on Ubuntu 12.04 with newest git, at least). I'd try it anyway. The above error you posted doesn't tell you anything about Pd's jack support. To see whether Pd's configure found jack you need to look much further up in the configure output, certainly above a line that says: === configuring in portaudio (/some/path/portaudio) There you should find something like: checking for jack_set_xrun_callback in -ljack... yes checking for jack_set_error_function in -ljack... yes I checked line 15417 in configure, but doesn't make any sense to me, unfortunately.. I don't know why portaudio's configure fails like this on Sabayon. plus some other stuff that don't seem write (out of intuition, not knowledge or experience) for example: checking machine/soundcard.h usability... no checking machine/soundcard.h presence... no checking for machine/soundcard.h... no checking for _oss_ioctl in -lossaudio... no I find the exact same lines in the output of my ./configure and everything is detected correctly and the resulting binary is working fine. Those lines do not necessarily indicate a failure. I also got lots of warnings when I typed make, like: msgfmt --check --tcl --locale=af -d . af.po af.po:6: warning: header field 'Language' missing in header It's only a warning. I'd ignore it. It probably has to do with localization of some texts (probably menus?) Don't know if this helps, the messages from configure are quite a lot, I could post them if it's more helpful. I have Jack1 installed When compiling software that is dependent on other software, it is usually not enough to install just the binaries of the other software. You need to also install the so-called headers of those other software. In Debian, packages delivering the header files have usually the '-dev' suffix in their name. So for compiling against Jack, you certainly need to have libjack-jackd2-dev or libjack0.100.0-dev installed. I don't know about Sabayon. If Sabayon is like Gentoo and all software you use is compiled on your box, then you might already have the necessary files installed. (there might be some issues there with memory allocation, but that should go to Jack's list, don't know if this influences Pd's compilation) and ALSA. I've been posting a lot on this Linux and Pd issue of mine lately, but I do wanna give this combination a try...sorry if I irritate anyone.. I don't think you do. Certainly not me. If someone has to go on an odyssey like you, it's good to have it documented somewhere, be it a mailing list. Something things are getting really cumbersome and you are most likely not alone experiencing that. You never know what details might prove useful for someone else. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [netsend](tcp) is much faster than [udpsend] why??
On Fre, 2014-01-17 at 18:48 +0100, Jonghyun Kim wrote: I found this result that [netsend] (tcp) is much faster than [udsend]. It tested on between Mac and Ubuntu connected within eth0. I don't know why udpsend is much slower than netsend. What are you measuring: throughput or latency? Maybe you can elaborate on your setup and on how and what you measure. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd on high resolution displays
Hi Ico That sounds awesome and like a lot of work. If this really means it will be possible to work on hi-res displays as comfortably as on older setups, this will be a huge advantage of pd-l2ork. Is that something that relies on other pd-l2ork specific changes or could that be easily back-ported to Pd? Roman On Don, 2014-01-09 at 18:16 -0500, Ivica Bukvic wrote: FWIW, recently there has been a fair amount of work in pd-l2ork with the new tkpath backend to allow for this. Currently we are able to scale everything but the text which requires development of a new widget. Once that is done the canvas will be completely scalable independently of font sizes. This, however, does not address the menus... On Jan 9, 2014 5:56 PM, Roman Haefeli reduz...@gmail.com wrote: Hi Recently, a few models of so called ultrabooks with comparatively high display resolution (up to 3200x1800px) are available, even with affordable prices. While the specs sound teasing, I wonder how Pd is going to behave on those. I'm especially interested in the situation on linux. This might be rather a Tk question, but it is possible to scale all Pd graphics evenly, so that the appearance will still be comfortable and all menu and patch fonts will readable? Setting the font size in patches won't really help as this scales only the boxes and there content, but not the menus, the iemguis and also not the distance between boxes. Is someone with a hi-res display stuck with lowering the resolution when the goal is to do some patching? 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] Pd on high resolution displays
On Don, 2014-01-09 at 15:46 -0800, Jonathan Wilkes wrote: In Pd Vanilla and possibly Pd-l2ork, tk menus and widgets should do the right thing because of something called tk scaling: http://wiki.tcl.tk/8484 In Pd-extended, tk scaling is hard-coded to 1 in pd-gui.tcl, but if you remove that line things should scale up accordingly. (Or reveal bugs in tk if things look wacky as a result.) Actually, in my version of Pd (0.45-4 from git tag, 0.45.0 in Pd's help), 'tk scaling 1' is commented out. Uncommenting it doesn't change anything in Pd. Also changing it to whatever value doesn't show any effect. If I understand the documentation correctly, a tcl/tk pogrammer should retrieve the display width+height and pixel resolution and calculate the proper tk scaling, right? You won't be able to scale iemgui sizes in any flavor of Pd. They are specified in pixel units. There is a canvas scale subcommand but the catch is that text items (i.e., most of the content of a patch) doesn't actually get scaled. Worse, tk canvas seems only to support integer font sizes, making it burdensome to try to use canvas scaling and manually tweak the font sizes to match. (I think Pd-l2ork currently does the reverse-- you choose a different font size and it picks a corresponding scaling factor, though I don't know if it actually uses the scale subcommand or not.) So burdensome is scaling text on a tk canvas that someone just decided to make their own mono-spaced vector font in tcl/tk using canvas curves, demo'd here: http://www.youtube.com/watch?v=n3sz_KRdRmY Why not use that font in Pd? It would make Pd look the same on every platform, wouldn't it? Or does that have other drawbacks? I like the video. Had to watch it to the end. It amazes me how the poster obviously finds never-ending pleasure in playing with that feature while listening to good music and humming along happily. It seems like a zen kind of thing ;-) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Check for batch and/or nogui mode from Patch
On Mon, 2014-01-13 at 20:26 +0100, Thomas Mayer wrote: Hi, is there a way to get information on whether Pd has been started with -batch or -nogui from inside a patch? Though I consider Cyrille's approach the clean way for your specific purpose, there is also a way to check for '-batch' without help from outside. Measure [delay 1000] with [realtime] and if the result is orders of magnitude smaller than '1000' (say 0.4), Pd has most likely been started with '-batch' (assuming it didn't do much during the 1000ms logical time). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd on high resolution displays
Hi Recently, a few models of so called ultrabooks with comparatively high display resolution (up to 3200x1800px) are available, even with affordable prices. While the specs sound teasing, I wonder how Pd is going to behave on those. I'm especially interested in the situation on linux. This might be rather a Tk question, but it is possible to scale all Pd graphics evenly, so that the appearance will still be comfortable and all menu and patch fonts will readable? Setting the font size in patches won't really help as this scales only the boxes and there content, but not the menus, the iemguis and also not the distance between boxes. Is someone with a hi-res display stuck with lowering the resolution when the goal is to do some patching? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Does CPU affinity help Pd's performance?
On Sun, 2014-01-05 at 21:46 +0200, Alexandros Drymonitis wrote: Also, I've installed indicator-cpufreq in order to set the CPU to a fixed frequency but that won't help either... My observation with similar setups (Pd on Ubuntu) is that CPU scaling doesn't react fast enough for Pd. When doing live music with lots of synthesizer patches, I often see the CPU stuck at the lowest frequency, although drop-outs occur. In performance situation I usually set the CPU frequency manually to the maximum value. My guess is, that even if doesn't help now, it might help you later, once you fixed your current problem. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] literal $0 from message to gui send and gui receive
On Fri, 2013-11-15 at 09:06 -0500, Billy Stiltner wrote: hey, I have been trying to rename sends and receives of dials at runtime they need actual literal $0 in their name. so I tried this with sending a 0 to $$4 in a message it worked for the literal renaming but the patch gets messed up after saving and reloading. I might have a found a way that doesn't mess up the patch after saving, but I still consider it somewhat hack-ish. I'm not clear of the purpose of what you want to achieve, though. You can only convert the receivenames to use $0 once, so it seems easier to use a text editor to edit the pd file. Or if you set the receive names dynamically whenever you fire up the patch, you could instead use the real number instead of the variable $0. Roman somehow the patch does need to be able to be edited and saved without changeing the $$4 to a $\$4 once reloaded after a save. this is what the patch looks like from the .pd file after a save. #X msg 188 -194 \; \$1-o\$2-waveform-rx receive \$$4-o\$3-waveform-rx \; \$1-o\$2-dt-rx receive-rx \$$4-o\$3-dt-rx \; \$1-env\$2-o\$2-dt-rx receive \$$4-env\$3-o\$3-dt-rx \; \$1-lfo\$2-o\$2-dt-rx receive \ $$4-lfo\$3-o\$3-dt-rx \; \$1-o\$2-pw receive-rx \$$4-o\$3-pw-rx \; \$1-env\$2-o\$2-pw-rx receive \$$4-env\$3-o\$3-pw-rx \; \$1-lfo\$2-o\$2-pw-rx receive \ $$4-lfo\$3-o\$3-pw-rx \; \$1-env\$2-o\$2-rx receive \$$4-env\$3-o\$3-rx \; \$1-lfo\$2-o\ $2-rx receive \$$4-lfo\$3-o\$3-rx; #X msg -109 -193 \; \$1-o\$2-waveform-rx send \$$4-o\$3-waveform \; \$1-o\$2-dt-rx send \$$4-o\$3-dt \; \$1-env\$2-o\$2-dt-rx send \ $$4-env\$3-o\$3-dt \; \$1-lfo\$2-o\$2-dt-rx send \$$4-lfo\$3-o\$3-dt \; \$1-o\$2-pw-rx send \$$4-o\$3-pw \; \$1-env\$2-o\$2-pw-rx send \$$4-env\$3-o\$3-pw \; \$1-lfo\$2-o\$2-pw-rx send \$$4-lfo\$3-o\$3-pw \; \$1-env\$2-o\ $2-rx send \$$4-env\$3-o\$3 \; \$1-lfo\$2-o\$2-rx send \$$4-lfo\$3-o\$3; __ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 59 73 524 299 10; #X obj 33 195 hsl 128 15 0 127 0 0 empty bla empty -2 -8 0 10 -262144 -1 -1 3100 1; #X obj 134 114 s bla; #X msg 134 28 list $ 0; #X msg 134 52 receive \$1\$2-bla; #X floatatom 26 54 5 0 0 0 - - -, f 5; #X floatatom 298 57 5 0 0 0 - - -, f 5; #X obj 298 118 s \$0-bla; #X obj 26 106 s bla; #X text 286 164 this even works after saving patch; #X obj 390 255 s \$0-bla; #X msg 390 230 receive bla; #X text 387 207 reset; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 4 0 7 0; #X connect 5 0 6 0; #X connect 10 0 9 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd activities/places at the west coast? netpd tour?
Hi all I'm traveling with my family at the west coast of North America, between Vancouver and San Francisco until the end of the year. We're certainly going to visit at least some of the major cities near the coast line. We don't have any particular plans or schedules, but I'd enjoy to take the chance to connect with Pd people in the areas we're going to visit. If you know of Patching Circles or have an exhibition running or know of any other Pd related activities, please drop me a line off-list. In shameless manner of self-promotion, I'm also looking for places to present netpd, either by giving workshops or having live jams with interested people. If you know of suitable locations, please let me know. Thanks and take care! Roman -- http://www.netpd.org/About -- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] modifying Reduzent's [Solenoiduino] to control 44 solenoids (electro-mechanical piano)
On Tue, 2013-09-10 at 21:34 -0400, Epic Jefferson wrote:
The modified version of the arduino sketch is included in the .zip in
my first email if you want to have a go at it. i haven't changed
anything on the pd side. I would rather sacrifice duty cycle
resolution and be able to control 64 solenoids, than making the entire
message longer and slowing down the entire system.
I adapted the bitmask stuff in the the Pd patch and the Arduino sketch
so that 6 bits are used for the pin address. This means, the velocity
has now only 256 steps. Check the attachments.
Beware, I wasn't able to actually test the modifications as I currently
don't have an arduino at hand.
As far as the dropped messages go, I'm sending separate messages by
packing the data and sending it to a single [trigger $1 $2{ message
box. I'll try sending separate messages to see if that helps.
I'm not totally sure if I understand you correctly, but this should be
fine, as long as [solenoiduino] receives 'trigger X Y' messages.
The main difference between your version and mine is that yours uses the
Tlc stuff. I don't know how this part behaves if you set and update
twice in a row very quickly. May be this is the culprit? Just a guess, I
can't test here and I don't have a clue what this code does or if it
does something time critical at all. A cheap work-around might be to
rate-limit the messages on the Pd side.
Regarding the handshake: You may skip that all-together if it doesn't
work for you, as it isn't really necessary. I thought it might be a
convenient way check to make sure the hardware has the correct firmware
loaded. To quickly test send 255 to [comport] and see if you get
something back. If so, the problem might be in the [solenoiduino]
abstraction.
Roman
On Tue, Sep 10, 2013 at 6:24 PM, Roman Haefeli reduz...@gmail.com
wrote:
On Tue, 2013-09-10 at 01:53 -0400, Epic Jefferson wrote:
To control solenoids with dynamics, I adapted Reduzent's
[Solenoiduino] abstraction and arduino sketch to include the
TLC5940
functions, which is what the Practical Maker PWM shield is
based on.
So far, I'm able to control 44 solenoids using custom
drivers and 2
stacked PWM shields. This is an excellent alternative if you
want to
build a relatively cheap electro-mechanical piano setup.
The problems i've run into:
1. if 2 or more messages get sent simultaneously, one
of them
might get dropped (this happens a lot)
This shouldn't happen and actually never happened in my own
experience.
A single 2-byte message sets and one pin to HIGH and sets a
timer for
that pin. So, if you need two set two pins simultaneously, you
need to
send two 2-byte messages. I don't see how the code could omit
a message,
unless two subsequent messages set the same pin.
If you modified the code, you can send me a copy, so I'll look
into it.
1. the handshake does not seem to work on Linux (Ubuntu
11)
It's pretty crude. Whenever you send it a '255' (0xff) byte,
it responds
with the following ASCII sequence: 'SOL 0 1'. You can easily
test that
with [comport] directly.
The ugly thing is that [solenoiduino] has to make sure not to
send any
0xff bytes and thus some values for periods are not allowed /
replaced,
e.g 127, 255, 383 etc.
1. the original code only supports 16 solenoids
This last one is the one that goes over my head, since the
code uses
that bit twiddling stuff, I can't figure out how to send the
appropriate messages to any solenoids past 15. So, I'm a
little stuck
here, any help?
The solenoiduino code uses two bytes per message, while the
first bit of
each is used for defining the byte order. This leaves 14 bits
for the
payload. The current implementation uses 4 bits for the pin
address and
10 bits for the duty cycle. If you can live with a lower duty
cycle
resolution, you can shift some bits around. For instance, you
could
adapt the bitmask to use 6 bits for the address (allows to
control 64
solenoids) and use only 8 bit for the velocity / duty cycle.
Alternatively, you could extend the protocol to use 3 bytes
per message.
This would give you a payload of 21 bits to be distributed
between
address and duty cycle. Of course, this reduces your maximum
message
rate by 1.5.
Roman
Re: [PD] modifying Reduzent's [Solenoiduino] to control 44 solenoids (electro-mechanical piano)
On Tue, 2013-09-10 at 01:53 -0400, Epic Jefferson wrote: To control solenoids with dynamics, I adapted Reduzent's [Solenoiduino] abstraction and arduino sketch to include the TLC5940 functions, which is what the Practical Maker PWM shield is based on. So far, I'm able to control 44 solenoids using custom drivers and 2 stacked PWM shields. This is an excellent alternative if you want to build a relatively cheap electro-mechanical piano setup. The problems i've run into: 1. if 2 or more messages get sent simultaneously, one of them might get dropped (this happens a lot) This shouldn't happen and actually never happened in my own experience. A single 2-byte message sets and one pin to HIGH and sets a timer for that pin. So, if you need two set two pins simultaneously, you need to send two 2-byte messages. I don't see how the code could omit a message, unless two subsequent messages set the same pin. If you modified the code, you can send me a copy, so I'll look into it. 1. the handshake does not seem to work on Linux (Ubuntu 11) It's pretty crude. Whenever you send it a '255' (0xff) byte, it responds with the following ASCII sequence: 'SOL 0 1'. You can easily test that with [comport] directly. The ugly thing is that [solenoiduino] has to make sure not to send any 0xff bytes and thus some values for periods are not allowed / replaced, e.g 127, 255, 383 etc. 1. the original code only supports 16 solenoids This last one is the one that goes over my head, since the code uses that bit twiddling stuff, I can't figure out how to send the appropriate messages to any solenoids past 15. So, I'm a little stuck here, any help? The solenoiduino code uses two bytes per message, while the first bit of each is used for defining the byte order. This leaves 14 bits for the payload. The current implementation uses 4 bits for the pin address and 10 bits for the duty cycle. If you can live with a lower duty cycle resolution, you can shift some bits around. For instance, you could adapt the bitmask to use 6 bits for the address (allows to control 64 solenoids) and use only 8 bit for the velocity / duty cycle. Alternatively, you could extend the protocol to use 3 bytes per message. This would give you a payload of 21 bits to be distributed between address and duty cycle. Of course, this reduces your maximum message rate by 1.5. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] compiling externals on ARM
I vaguely remember that you need only the 'externals' folder from svn, but also 'packages' for compiling the externals from svn. Checkout 'packages' and try again. Roman On Tue, 2013-09-10 at 11:25 +0200, Cyrille Henry wrote: hello, nusmuk-audio use the template makefile. i upgrade it to last version for ali to test. anyhow, this lib compile fine almost everywhere, including on rasbian. (so makefile look good on linux/arm) ali say that compiling any externals gives the same problem. so it's not specific to this lib. i have no idea where the problem source can be. cheers c Le 10/09/2013 11:09, katja a écrit : Actually I think that the library template should work for Linux on ARM too, as is. Only it does not provide specific optimization flags, which those ARM boards sorely need for performance. But if it does not build at all, there may be something else wrong, for example the build directory structure. Let's not conclude too early that the makefiles are at fault. Katja On Mon, Sep 9, 2013 at 6:29 PM, jo57 jaime.oliv...@gmail.com wrote: I don't think it is clutter at all… I don't have one of these boards, but I'd love to try them, and when I do, I'd love to come back to this documentation... Perhaps this could be added to the library template? http://puredata.info/docs/developer/LibraryTemplate J On Sep 9, 2013, at 11:39 AM, katja katjavet...@gmail.com wrote: Hi Ali, Seems an interesting board, the Udoo. PengPod has Cortex-A8 while Udoo has Cortex-A9. But machine name is armv7l in both cases, meaning the same compiler flags may be used. If you want I can send you a project by private mail (don't want to clutter the list with this) which builds some home-brew externals and some externals from Pd-extended on RPi and PengPod amongst others. If it would build on Udoo too, we'd know a bit more. Katja On Mon, Sep 9, 2013 at 4:11 PM, Ali Momeni batc...@gmail.com wrote: Hello, Looks like the Udoo is the same as the PengPod. Is the PengPod something like: http://pandaboard.org/ ? Here's what i get: ubuntu@imx6-qsdl:~$ uname -s Linux ubuntu@imx6-qsdl:~$ uname -a Linux imx6-qsdl 3.0.35 #1 SMP PREEMPT Mon Aug 19 07:11:31 PDT 2013 armv7l armv7l armv7l GNU/Linux On Mon, Sep 9, 2013 at 10:03 AM, katja katjavet...@gmail.com wrote: Hello Ali, A while ago I've compiled home-brew Pd externals on Raspberry Pi and PengPod Linux tablet, and found that for each ARM processor type you can identify them by their proper name as returned by command uname -m. For RPi this is armv6l and for PengPod armv7l. So I could define individual flags for those ARM types in the makefiles. There is no general approach to this, as makefiles in various Pd extended libs can be very different. In the template makefile which is used for many libs, the operating system is tested first with uname -s. If it is Linux, the processor type is found with uname -m and stored in variable CPU, which seems to be used for target 'showsetup' only, not for setting specific flags. Anyway, if you get No rule to make target xxx.pd_linux when trying to build a lib with template makefile, I wonder what you get from your Udoo board with command uname -s? Katja On Mon, Sep 9, 2013 at 2:06 PM, Ali Momeni batc...@gmail.com wrote: hello all, i'm working with a Udoo board (http://Udoo.org) i've successfully compiled PureData 0.45 from miller's site; i'm now trying to compile some of the externals in the pd svn, but i'm getting the same error for all. for instance, when trying to compile nusmuk-audio, i.e. http://sourceforge.net/p/pure-data/svn/17203/tree/trunk/externals/nusmuk/nusmuk-audio/ i get the following ubuntu@imx6-qsdl:~/pd-externals/nusmuk/nusmuk-audio$ make make: * No rule to make target `bq~.pd_linux', needed by `all'. Stop. I have contacted the developer (cyrille henry) and he adjusted the MakeFile to account for building for ARM; but i get the same error. I notice, incidentally, that i get the same error (No rule to make target xxx.pd_linux) for all other externals that i tried from the repository. does anyone have any thoughts on how to resolve this? thanks, ali ___ 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 -
Re: [PD] [PD-announce] pd 0.45-1 released
On Wed, 2013-08-28 at 13:15 -0700, Miller Puckette wrote: Pd 0.45-1 is up on the usual - http://crca.ucsd.edu/~msp/software.html Menu 'Window' - 'Parent Window' is broken. When used, the following error is printed: error: canvas: no method for 'findparent' verbose(4): ... you might be able to track this down from the Find menu. This is not new to 0.45.1, but has probably been there since all 0.45 versions. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] MIDI port
I'm not totally sure, but I believe that: Midi Port 1 is mapped to channels 1-16 Midi Port 2 is mapped to channels 17-32 Midi Port 3 is mapped to channels ... you get the idea. Roman On Fri, 2013-08-16 at 12:00 +0200, Fero Kiraly wrote: Yes,I use [noteout] but it accepts only MIDI channel # not MIDI port #. How to achieve this? On Aug 16, 2013 11:20 AM, Ed Kelly morph_2...@yahoo.co.uk wrote: Hi, You're probably better off using [ctlout], [noteout], [bendout] for specific types of MIDI data. Cheers, Ed Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/ Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Fero Kiraly fero.kir...@gmail.com To: pdlist pd-list@iem.at Sent: Friday, 16 August 2013, 10:10 Subject: [PD] MIDI port hi guys, how to distribute MIDI msgs to MIDI ports ? I tried [midiout] but what are the raw data? thanks fero ___ 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] How to reduce CPU use on unused subpatches-abstracts?
On Wed, 2013-08-07 at 08:40 +0200, IOhannes m zmölnig wrote: On 08/07/13 03:15, Miller Puckette wrote: Hmmm... I was umnder the impression that, except for the overhead of block~ and switch~ objects, there would be no difference in DSP execution time between a patch having lots of subpatches and one with the same amount of computation all thrown in one window. I haven't made any measurements but theoreticall at least there shouldn't be any difference. i once did make measurements, and they showed that your assumption is correct. or at least, it showed that it *was* correct at that time. this was on a P2-400MHz in 1998 or so, where a 16 channel spatialization patch would eat about 95% of the CPU - regardless of whether you used a single huge patch or organized the code into subpatches/abstractions. eventually i went for using abstractions, and let the PC run at 95% for the 2 weeks show. I once made some informal tests to measure the overhead of [switch~]. It turned out it is quite big and if you're running hundreds or thousands instances of [switch~] you probably gain nothing by turning DSP off in subpatches. I don't know what the sweet spot is it seems using [switch~] is only worth for subpatches with a minimum amount of (DSP) complexity. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] routeOSC - dynamic routing?
On Wed, 2013-08-07 at 02:15 -0400, pured...@11h11.com wrote: hi all, i have more than 50 OSC messages to [routeOSC], i would like to avoid having to cut and paste click and drag. what are my options here? [routeOSC /knob1 /knob2 ...] | | [s $0-knob1] [s $0-knob2] thanks Instead of routing with [routeOSC], you could use the last address field directly as the send address: [/knobs/knob1 23( | [routeOSC /knobs/ | [list] | [; $1 $2( As an alternative to the ;-messagebox with hard-coded number of elements, you could employ a settable [send] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] alternative to gridflows #many
On Mon, 2013-08-05 at 10:45 +0200, Felix Obée wrote: hi everybody, i used gridflows #many in some of my patches to have a toggle matrix and such. Unfortunately for some reason I can't get gridflow to work on my new system (mountain lion) and i saw that it hasn't been developed in some time. are there alternatives to #many implemented in other libraries? I don't know the specifics of [#many], but you certainly can create 2d-arrays of toggles with data structures. To give you some ideas: A sequencer abstraction that uses a 2d grid of toggles: http://lists.puredata.info/pipermail/pd-list/2013-06/102940.html A frontend to [iemmatrix/mtx_*~] by João Pais: http://lists.puredata.info/pipermail/pd-list/2013-07/103405.html Maybe you can strip out what you need from one of above examples. Cheers Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to reduce CPU use on unused subpatches-abstracts?
Hi Mario Check [switch~] and its help patch. Roman On Mon, 2013-08-05 at 09:03 -0300, Mario Mey wrote: Hi, there... I really need some help. I'm working on a looper-multi-effects (big) patch. It has more than, more or less, 100 stereo FXs. They are all inside the patch as abstracts. But, to avoid them to consume CPU, each one has a [switch~ 0] if it is not working. So, there're only two FX at a time, where the DSP is on. Something like this: Main patch: adc~ | \ | [s $0-pre-r] [s $0-pre-l] [catch~ $0-post-l] | [catch~ $0-post-r] |/ [dac~] (the same for Each FX as file-abstracts (using [fx1 $0] to call them) inside the main patch: [r $1-pre-l] [r $1-pre-r] | / [The-FX-itself.] | \ [throw~ $1-post-l] [throw~ $1-post-r] [0( [1( | / [switch~] This technics DOES work very well. Buuut... when having 100 FX at the same time (even not working), the CPU increase 15-20%. I repeat, there're only two FX working at the time. The rest are turned-off. For now, the CPU use is: Ready-to-use, 2 FXs on, DSP on: 47% Recorded and playing 8 stereo-banks, 2 FXs being used, DSP on: 60 - 62% (I have quite a few XRUNS) Ready-to-use, 2 FXs on, DSP off: 7% As you can see, the non-signal processing is very low. What I think is that each FX is working when receiving and/or throwing signal (200 [receive~] and [throw~] objects)... even they are sending and/or processing nothing. Is there any other way to connect all the FXs to the main patch and to have a lower CPU consumption? Maybe [inlet~] and [outlet~] consume less CPU? (I should connect all the FX at hand... or find a aumotated way to do it) Thanks a lot. Mario Mey ___ 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] polygate~, demux~ mux~, mtx_*~
On Sam, 2013-07-27 at 18:08 -0400, pured...@11h11.com wrote: hi, i need to route 1 to x x to 1 audio signal. demux~ (demultiplex~ on pd-extended) and mux~ are doing exactly that, but when switching using a number box = glitch. polygate~ have a fade option that avoid this glitch but there's no couterpart (like unpolygate~) and finally mtx_*~ on pd-extended linux 64, i cannot create the object (i don't know what to import). [mtx_*~] is part of iemmatrix. And due to the way of how it is packaged in Pd-extended and due to some character restrictions for filenames, you need to use [hexloader] to load it. Try: [import hexloader iemmatrix] [mtx_*~] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] object test - matrixctrl, GUI for mtx_mul~
Hi João Nice and handy abstraction! Since it outputs 'matrix' messages, it would be nice if it would accept 'matrix' messages as input to set the initial state. This would make state saving/restoring even simpler. @colors: Mike probably means it'd be nice to be able to set the color of toggled and non-toggled cells. Roman On Wed, 2013-07-10 at 02:34 +0200, João Pais wrote: what do you mean exactly? This is very useful, thanks! The only suggestion I have would be able to change the colors somehow. ___ 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-announce] netpd session recording
Hi Let me share the recording of a netpd session I had yesterday with Sqgl from Sydney. I like it myself and thus I thought it might be worth sharing: http://www.netpd.org/sessions/2013-07-09_prism-breaks.mp3 Sqgl and me are having regular sessions every Tuesday at ~08:00 UTC (this is 10 in the morning for most of Central Europe and evening for Westaustralia). Everyone is invited to join. Roman --- http://www.netpd.org --- ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] phasor~: change freq on wraparound
On Don, 2013-07-04 at 21:20 +0200, Orm Finnendahl wrote: Hi List, sorry if I'm missing the obvious: I'd like to implement a phasor~, which only allows its frequency to be changed on wraparound. Using a samphold~ for that purpose connected to the outlet and inlet of the phasor~ doesn't work as this creates a dsp loop. I prefer a pd vanilla solution (I know how to implement it as an external, but for portability I'd like to get it done without). Any ideas? Sounds like a job for [vline~]. See attached patch. Roman #N canvas 164 176 427 401 10; #X obj 113 330 vline~; #X msg 113 303 0 \, 1 \$1; #X obj 113 255 metro; #X obj 113 277 f; #X obj 140 221 t a a; #X obj 140 198 /; #X msg 140 174 1 \$1; #X obj 113 352 outlet~; #X obj 27 200 loadbang; #X obj 140 16 inlet; #X obj 140 88 sel 0; #X msg 140 136 1e-23; #X obj 167 112 min 1000; #X obj 202 23 loadbang; #X obj 202 45 f \$1; #X connect 0 0 7 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 4 0 2 1; #X connect 4 1 3 1; #X connect 5 0 4 0; #X connect 6 0 5 0; #X connect 8 0 2 0; #X connect 9 0 10 0; #X connect 10 0 11 0; #X connect 10 1 12 0; #X connect 11 0 6 0; #X connect 12 0 6 0; #X connect 13 0 14 0; #X connect 14 0 10 0; #N canvas 439 225 549 308 10; #X obj 74 116 phashold~ 2; #X floatatom 74 48 5 1 1000 0 - - -, f 5; #X obj 75 222 snapshot~; #X obj 78 246 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144 -1 -1 11222 1; #X obj 161 168 loadbang; #X obj 161 190 metro 20; #X text 180 20 similar to [phasor~] \, but only changes to new frequences only at wrapping time.; #X text 178 82 NOTE: the range of allowed frequencies is limited between 1e-23 and 1000 Hz. To allow higher frequencies \, the [metro] needs to be replaced by [delay] based construct.; #X text 407 277 2013 \, Roman Haefeli; #X connect 0 0 2 0; #X connect 1 0 0 0; #X connect 2 0 3 0; #X connect 4 0 5 0; #X connect 5 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote: On Jul 3, 2013 1:38 AM, Roman Haefeli reduz...@gmail.com wrote: On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote: [symbol\ | [label $1( | [cnv] - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP). According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended. This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility. If a patch just isn't usable at all on a different flavor, then I don't see how this doesn't qualify for breaking compatibility. Roman I guess we need to clarify what not usable at all means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily. Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this. This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches. If you are looking for things that really break compatibility, then those would be things like preset_node object that are current only possible in pd-l2ork. Actually, one can decide to use or not to use new features. Obviously, added features do not work in flavors that do not implement that feature. From a user point of view, this can be dealt with in an clean way. If you want your patch to work on other flavors, don't use stuff like preset_node. I don't see a problem at all with that. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Wed, 2013-07-03 at 05:53 -0400, Ivica Ico Bukvic wrote: On 07/03/2013 04:31 AM, Roman Haefeli wrote: On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote: I guess we need to clarify what not usable at all means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily. Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this. This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches. The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices: 1) keep the same inconsistent behaviour for as long as it exists causing problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me) 2) fix this at some later date at which point you will have a larger library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable. tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd. Thanks for your considerations. I actually agree with you in every respect. I also wouldn't mind having GUI glitches fixed in pd-extended| pd-vanilla, even if it means having to go through all my patches to fix them. However, things haven't changed in pd-vanilla|pd-extended yet and I see myself forced to decide which route to go. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bytes to string
On Wed, 2013-07-03 at 16:36 +0200, Charles Goyard wrote: Hi list, apologizes, this looks like a FAQ, but I can't find anything in the archives (wrong keywords ?) for this. I just want to turn the bytes from comport output into a list. From a serial monitor, my program outputs: 1.23 456 789\n I get it correctly into pd and it seems to work. But it looks ugly and I feel it could be better done. I don't see how it could be improved much. Why is it ugly? The only smallish improvement I see is the way you convert a stream into lists. The recursive [list prepend] approach gets more and more inefficient the longer the list gets. You could use a message box instead and add your bytes with [add2 $1(. And on termination (sel 10) send a 'bang, set' to output the finished list and empty the message box. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote: On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduz...@gmail.com wrote: On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: I'm reformulating my question as the problem is evolving: do we have an object that - Displays and holds a text value (like Symbol or Message box), * symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' message Very good idea, thanks Roman! Some difficulties I'm having: - I don't know how to set the label of [cnv]... is it possible at all? [symbol\ | [label $1( | [cnv] - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP). According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
On Die, 2013-07-02 at 17:07 +0200, Matthias Geier wrote: Hi Iain. To be honest, I didn't think about the problem that a message could need more than one packet. It's good to know that iemnet/tcpclient can handle that. It's not that [iemnet/tcpclient] can handle it and [net/iemnet] can't. In fact, with both you have to cook your own mechanism to delimit packets for a packet oriented protocol. With [net/iemnet], however, you have to serialize the data first in order to be able to do that. I see two problems with [net/tcpclient]'s implementation: * you have to serialize the data anyway, so why doesn't the object already do it? * It gives you the false impression of dealing with packets when you in fact are dealing with a stream. It's dangerous because it often looks as if it would be working, but there is no guarantee it will always do. You may receive a packet split into many chunks, or you get a big chunk containing several packets. All those cases are valid from to POV of TCP, but will break your protocol unless you deploy proper delimiting. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Die, 2013-07-02 at 17:58 -0400, Jonathan Wilkes wrote: On 07/02/2013 02:41 PM, András Murányi wrote: On Tue, Jul 2, 2013 at 2:27 PM, Roman Haefeli reduz...@gmail.com wrote: On Die, 2013-07-02 at 12:54 +0200, András Murányi wrote: On Mon, Jul 1, 2013 at 10:05 PM, Roman Haefeli reduz...@gmail.com wrote: On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: I'm reformulating my question as the problem is evolving: do we have an object that - Displays and holds a text value (like Symbol or Message box), * symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' message Very good idea, thanks Roman! Some difficulties I'm having: - I don't know how to set the label of [cnv]... is it possible at all? [symbol\ | [label $1( | [cnv] my [cnv] has no inlets so IOhannes's solution applies. The [cnv] object has no inlet. Yeah, my mistake. Didn't check when writing the mail. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
On Die, 2013-07-02 at 18:15 -0400, Martin Peach wrote: On 2013-07-02 16:13, Roman Haefeli wrote: On Die, 2013-07-02 at 17:07 +0200, Matthias Geier wrote: Hi Iain. To be honest, I didn't think about the problem that a message could need more than one packet. It's good to know that iemnet/tcpclient can handle that. It's not that [iemnet/tcpclient] can handle it and [net/iemnet] can't. In fact, with both you have to cook your own mechanism to delimit packets for a packet oriented protocol. With [net/iemnet], however, you have to serialize the data first in order to be able to do that. I see two problems with [net/tcpclient]'s implementation: * you have to serialize the data anyway, so why doesn't the object already do it? I think I implemented it that way because it seems to be more efficient within Pd to deal with a single list rather than a bunch of floats. But I don't know for sure if that is true. Yeah, this is what I assume as well, though I don't have any data to back up that assumption. On the other hand, serializing might be cheaper on the C side than in Pd. I just cannot think of a use case where you actually want to directly use those chunks as received. Either you need to delimit packets, then you need to serialize the data, or you actually need a stream, but then you also need to serialize the data. * It gives you the false impression of dealing with packets when you in fact are dealing with a stream. It's dangerous because it often looks as if it would be working, but there is no guarantee it will always do. You may receive a packet split into many chunks, or you get a big chunk containing several packets. All those cases are valid from to POV of TCP, but will break your protocol unless you deploy proper delimiting. Well the TCP protocol _is_ splitting a stream into packets. It's not the same as a serial link where you can send bytes one at a time whenever you like. If you try that you will find that the bytes are gathered into packets for you. It might be useful to consider this when thinking about the best way to send the data (e.g. one byte per packet is not efficient, and you might get the false impression that TCP doesn't work very well). Since the TCP stack is free to packetize the data in the most efficient way, the application layer does not have to, or even _must_ not consider chunk size of data. This should be handled transparently by the transport layer. When the application transmits thousands of 1-byte chunks, the TCP layer will most likely send them as bigger chunks over the network. From the application's point of view, TCP is _exactly_ behaving like a serial link (just without a clock). And as I always say, UDP is probably a better choice for what you are trying to do, if it involves real-time control, with UDP you _do_ have control over the packet size. Agreed. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Die, 2013-07-02 at 19:15 -0400, Ivica Ico Bukvic wrote: [symbol\ | [label $1( | [cnv] - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP). According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended. This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility. If a patch just isn't usable at all on a different flavor, then I don't see how this doesn't qualify for breaking compatibility. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-extended crashes sending data to SSR with tcpclient
On Mon, 2013-07-01 at 13:20 -0400, Martin Peach wrote: It could be that you are overloading Pd with too many messages. If you are wildly moving the slider and [tcpclient] is sending one TCP packet per value you can add messages to the queue faster than they will be sent out and Pd will eventually run out of resources. There seem to exist different approaches to address this problem. If I'm not mistaken, [netsend] uses a fixed buffer and when filled it blocks Pd until the buffer gets emptied. [iemnet/tcp[client|send]] allocates just as much RAM as it needs and does not block Pd. If [net/tcpclient] really is designed to crash Pd when the buffer gets full, then I would think this is the least desirable behavior of all three. @Iain If it really crashes due to network saturation can easily be verified by testing the same patch with [iemnet/tcpclient]. If you throw more messages at it than it can actually transmit, you would notice an increasing lag on the other end. Roman On 2013-07-01 11:53, Iain Mott wrote: I'll try the backtrace and other things you suggest and report back on mrpeach/tcpclient in another email. it could well be, that it only does not crash with [iemnet/tcpclient] because you haven't parsed the output yet... Don't think so - to crash Pd, I wasn't doing any parsing of incoming messages - just sending messages out. Did a backtrace using mrpeach/tcpclient - on a freeze as it didn't actually crash. Got this response: #0 0x00442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 #1 clock_unset (x=0x8c5c80) at m_sched.c:62 #2 0x0044266e in clock_set (x=0x8c5c80, setticks=optimised out) at m_sched.c:81 #3 0x7fffd21cfec1 in tcpclient_child_send (w=0xdec548) at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 #4 0x77bc4e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x76ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x in ?? () Will do some more tests later. 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On Mon, 2013-07-01 at 20:56 +0200, András Murányi wrote: I'm reformulating my question as the problem is evolving: do we have an object that - Displays and holds a text value (like Symbol or Message box), * symbolbox with width set 0 resizes dynamically * hsl, vsl, cnv, etc. can adjust size with 'size' message, can change displayed text with 'label' message - is Graph-on-Parent, applies to all above solutions. - can be resized (like Number2)? (or small enough by default?) see above. To make something send a bang, you could put some [bng] objects behind your whatever text displaying objects. Interestingly, hidden GUI objects have priority over visible objects when clicked. Another way is to use a construct like the following to make a slider send bangs only when clicked, but not when dragged: [hsl] | [t a a] \/ /\ [sel 0] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] closed window not destroyed? (in l2ork, possibly in others too)
On Tue, 2013-06-18 at 22:58 +0200, András Murányi wrote: Hi List, I've got used to putting my PC to sleep (aka hibernation) often lately. Now there is this behaviour of Pd that when you leave a patch open and put the computer to sleep, once it wakes up Pd will try to do everything it missed while the computer was sleeping, so the CPU goes 100% for quite a while. I suppose this is by design. What I've just noticed using l2ork is that I had closed my patch before hibernating (in order to avoid the CPU boost when waking up), put the computer to sleep for a few hours, and when i woke it up, surprisingly the 100% CPU boost still happened - with only the main window and console open. This makes me think some things are not destroyed properly when a patch is closed. Any thoughts appreciated... Does it help to toggle DSP off and on, when Pd is in this post-suspend mode? I had the impression it did, but I wasn't sure if it was just a coincident, that CPU usage stopped at the same moment. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: right angle connections
On Fre, 2013-06-14 at 12:38 +0200, Charles Goyard wrote: Simon Wise wrote: Its all really a matter of taste ... it has come up many many times over the years, and nobody who could implement them seems to want segmented cords enough to actually do the work. Desire Data did Bezier curves. Having the feature does not force people to use it. The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it. I'm not sure if this is really a problem. Pd 0.45 supports setting a box width (for objects, messages, comments) that is saved with the patch. Those patches still can be opened and read by previous versions of Pd. This is done by storing the box width after a comma on the object creation line: #X obj 135 129 osc~ 3000, f 25; Similarly, this could be done for connections: #X connect 0 0 1 0, add some connection props here; Of course, this information is lost when saving the patch with a Pd that doesn't understand the format extension. Also, the extension might cause an older Pd to print an error. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Data structures: no object for freeing pointers?
On Die, 2013-06-11 at 11:00 +0200, Jan Baumgart wrote: I've been building a sequencer with data structs. But now I've come to a dead end, because there seems to be no object, that let's you remove structs. The only way seems to be deleting them in the gui. I think that is one of the limitations of data structures in Pd. You can clear a whole canvas, but not a single scalar, programmatically at least. The limitations of data structures have been discussed recently: http://lists.puredata.info/pipermail/pd-list/2013-05/102808.html a bit less recent post: http://lists.puredata.info/pipermail/pd-list/2011-04/088309.html Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Data structures: Detect array changes
Hi all Actually, the same question applies to normal tables as well, but I know that plain Pd does not provide a way to detect changes, whereas Pd-l2ork does. What about data structure arrays? Is there some hidden way to detect changes? I can detect clicks, but I found nothing else. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Data Structures: Lower and upper bound for graphical arrays
On a related note, is there a way to limit y for arrays with mutable y? If there'd be a way to detect changes, this would be actually easy to implement. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Data Structures: Lower and upper bound for graphical arrays
On Die, 2013-06-11 at 08:37 -0700, Jonathan Wilkes wrote: __ From: Roman Haefeli reduz...@gmail.com To: pd-list pd-list@iem.at Sent: Tuesday, June 11, 2013 6:02 AM Subject: [PD] Data Structures: Lower and upper bound for graphical arrays On a related note, is there a way to limit y for arrays with mutable y? If there'd be a way to detect changes, this would be actually easy to implement. There isn't a way to detect changes. But you can limit y with the -y flag of [plot]: [plot -y y(0:100)(0:100) etc.] Ah, that is much more elegant than what seems impossible. Nice, thanks! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiblob tracking in Gem while objects keep their IDs
On Thu, 2013-06-06 at 18:18 +0200, Jack wrote: Le 05/06/2013 22:17, Max a écrit : wow, this looks so wrong! (your screenshot) I have no idea why this is. I just tried it under Linux mint 15 (through ssh- XY from os x) Pd 0.43.2 GEM: ver: 0.93.3 GEM: compiled: Sep 6 2012 and it works perfectly there. on my other machine, os x 0.44.0-extended-20130213 GEM: ver: 0.93.3 GEM: compiled: Nov 10 2011 it also runs nicely. I'm afraid I don't know why it isn't running on your machine. can anyone else try it? max Am 04.06.2013 um 13:38 schrieb Antoine Villeret antoine.ville...@gmail.com: hi, 2013/6/2 Max abonneme...@revolwear.com Am 30.05.2013 um 14:06 schrieb Antoine Villeret antoine.ville...@gmail.com: hi, I'm sorry it still doesn't work and I can't find values that works well on the testbed.mov video... I don't know why, tell me if you want more info or snapshots Did you download all of the files, especially the abstractions you'll need for 07b-multi-blobtracker-IDs.pd? i've cloned the Bewegungsmelder repository Were there any messages, errors, warnings in the console? nothing explaining that in the console, nothing in the terminal with quicktime4linux or gmerlin backend : [pix_film:audio_ffmpeg] Codec not found: FFmpeg Sonic decoder [pix_film]: loaded file: /home/antoine/pd/Bewegungsmelder/testbed.mov with 623 frames (480x320) at 25.00 fps What OS and Pd/Gem version are you using? Ubuntu 12.04 Pd 44.2 Gem 0.93.git f890f4d here is attached a screenshot of what i get I was guessing a video decompression artefact but I got the same result with all the backends I have that can open testbed.mov (quicktime4linux and gmerlin) but I got the same result with both... I also converted the video to mjpeg and to h264 and got the same... very strange... + a m. Capture du 2013-06-04 13:06:45.png Hello Max, I have the same results than Antoine. A screenshot is attached. Configuration : Ubuntu 13.04, Pd 0.44.3, Gem ver: 0.93.git 374f713. Just an uneducated guess: Could it be that this is caused by objects being positioned on the same Z-plane (or quite close to each other) so that some overlapping occurs on some gfx cards, but not on some others? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Differences between: VD~ und delread~
On Don, 2013-05-30 at 13:00 +0200, hghoyer wrote: Hi, VD~ und delread~ are both processing Data / delayed sound from delwrite~ what is similar and what are differences between VD~ und delread~ ? The help files are pretty clear about it. [vd~ ] is controlled by a signal and it performs a 4-point interpolation. [delread~] is controlled by message and doesn't do any interpolation, thus its delay time is quantized to full samples. I haven't measured, but I'd expect [delread~] to use slightly less CPU cycles than [vd~]. If you need smooth delay time transitions, [vd~ ] is the way to go. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] first exercise with data structures
Thanks for sharing your mind on the topic. Probably this has already been covered as a limitation and may I haven't really understood it. There is one thing troubling me at the moment. From what I can see, you can easily get data out of your data structure. And for what I am trying, editing data manually/per GUI is quite easy. But how to set data programmatically, i.e. by message? As you can only change a certain scalar by setting a pointer to it, the only way I see is to traverse all scalars until you find the one you want to change. Is this currently the only way to change a property of a particular scalar? Roman On Sam, 2013-05-25 at 12:13 +0200, João Pais wrote: jonathan already gave a smart reply to your question, using variable variables as delimiters in your polygons, you can vary everything. If you notice, in your first example you could vary the position of the individual array elements (because you don't have a fixed x distance), but you couldn't vary the position of the whole array - which wasn't necessary for now, but I just wanted to remark that. I would add only something to your [setsize bar_struct bar_array] construct: in case you want to get a pointer of a specific template, use the template's name as argument e.g. [pointer bar_struct], and route the exit of the 2nd outlet to a [next(. That creates a loop that only stops when you get your pointer. if you have several scalars of the same template, adding a [get ...] to that loop makes it better (in case you have a sort of identifier for each scalar). A not-so-efficient-as-Jonathan's example of dynamic polygons can be seen in my [jmmmp/bezier] abstraction (attached also the upcoming audio version). Inside my folder are a couple other abstractions using data structures (some new ones might appear only in the next pd-ext release). I wouldn't say don't bother with data structures, but rather work a lot with it and make pressure so that they get improved. besides Jonathan's remarks, there are many other simple things that make life harder: lack of methods for simple operations (select previous pointer, or previous/next X pointers), math or expr functions inside of data-s templates (you need to get the data and then set it again), can't delete scalars without using the delete key or clearing the whole canvas, ... many small things that make one patch a lot just to make simple operations. and the biggest problem, rendering. don't even try to think of using data-s for any high-rate GUI. for that better to look at GEM. looking at Miller's words, data structures was one of the main reasons to start Pd. after all this time, they didn't change that much. very nice would be to have Ircam's FTM library implemented in Pd, but it seems to be an impossible task, someone has tried already. On Fre, 2013-05-24 at 16:13 -0700, Jonathan Wilkes wrote: Here's a quickly made approach that uses quanta syntax and checks for mouse manipulations from the outlet of [struct]. Thanks a lot. A lot of new stuff (for me) in your example. I wouldn't recommend spending too much time learning data structures. They are _extremely_ limited with the current implementation. I appreciate your advice. I have the impression one finds out about the limitations only by diving into data structures a bit more deeply. Although I haven't a clear picture yet what is possible and what is not, I find some of the examples in Millers documentation quite intriguing. Roman - Original Message - From: Roman Haefeli reduz...@gmail.com To: pd-list pd-list@iem.at Cc: Sent: Friday, May 24, 2013 6:15 PM Subject: [PD] first exercise with data structures Hi all Finally an attempt to dive into data structures. I read Frank Barknecht's still excellent DS tutorial and, of course, section 4 of Pd's help written by Miller Puckette, which is a bit more demanding, but definitely very interesting. Though I can somewhat follow the simpler example patches, the fundamental concepts are still a bit nebulous. Here's my problem. I found how to use [filledpolygon] to draw a rectangle whose width can be changed by mouse interaction. When using the same [struct] as the element of an array, I can draw many rectangles which can be grabbed and moved by the mouse (x-y-array). However, when it is used as an element, the ability to change the width dynamically with the mouse is lost. When it is not part of an array, it cannot be moved easily (without going into edit mode). How can I have both at the same time? Is it even possible at all? Attached is an example that illustrates both cases. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing
[PD] more about DS
Hi all Is it possible to have a scalar with a settable position, but which cannot be moved with mouse interaction? I figured I can use arrays to create grids of immutable scalars, but then I don't know how I can detect which specific element/scalar has been clicked on. Thanks, Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] first exercise with data structures
On Die, 2013-05-28 at 11:25 +0200, João Pais wrote: Probably this has already been covered as a limitation and may I haven't really understood it. There is one thing troubling me at the moment. From what I can see, you can easily get data out of your data structure. And for what I am trying, editing data manually/per GUI is quite easy. But how to set data programmatically, i.e. by message? As you can only change a certain scalar by setting a pointer to it, the only way I see is to traverse all scalars until you find the one you want to change. Is this currently the only way to change a property of a particular scalar? yes, you can only get or set data if you point to the relevant scalar. clicking allows you to get a pointer (for any method you want), but if you do everything with the program, you need to traverse until you get it right. for that I usually create an identifier (number, symbol, whatever) that I use to confirm if I have the correct reference before editing it. the method was explained in a previous mail. I guess the way you get the relevant pointer will vary on the program, difference contexts have different needs. Yeah, it depends on the data. I'm currently working with a rectangular grid of scalars and I figured I can easily translate the scalar's coordinates to the right number of 'next' messages in order to move the pointer to the desired scalar. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
