[PD] iem_sqrt4~ crashes on linux 6 bit
hey iem_qrt4~.pd_linux crashes the newest pd-extended as well as the latest pd source from sourceforge on ubuntu studio 13.04. I didn't want to mess with trying to figure out how to fix the source so I just made an iem_sqrt4~.pd that has a sqrt~ inside now all the iemlib vcf filters work . some of the vcf pd files had an iem_cot~ instead of iem_cot4~ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
I'm just having trouble with the specifics. Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach? Also, what is the metric to use here? To compare apples to apples, imagine that every g_* sourcefile has already been moved to the GUI side of both the single- and double- threaded designs that are being compared. -Jonathan On Sunday, February 23, 2014 12:30 AM, Rich E wrote: On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes wrote: On 02/20/2014 09:50 PM, Rich E wrote: > > >> >> >>On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote: >> >>On 02/18/2014 11:11 PM, Rich E wrote: >>> >>> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox wrote: Ah wait, duh. Of course the graph needs to know positioning, that's how it determines execution order or independent blocks of objects right? > > >On Jan 13, 2014, at 5:14 PM, Dan Wilcox wrote: > >Does the dsp graph rely on positioning? I thought only via connections. >I'd imagine the gui wrapper should only worry about positioning and simply >update those changes when saving. > IMO a separation between GUI and core could/would include position, e.g. objects have their connections mapped by an index, GUI assigns the index to the object based on position. This would allow for some much more sophisticated GUI's, such as 3d, or even a more human-readable text version (json has been mentioned). >>> You run into problems when you want to get decent GUI interaction _and_ expect to deliver audio to the soundcard in realtime. >>> >>> >> >> >>The GUI and audio shouldn't be updated from the same thread. This is one >>nice thing about libpd, it forces a separation. > What are the drawbacks to the multi-threaded approach? Specifically, for a full-fledged editing environment where you can't easily predict what the userbase is going to come up with inside the GUI? > > > Firstly, I think the decision should at least be available (to process audio and GUI on separate threads), since this is the most common way to handle the two different update rates. Especially since, with most GUI frameworks, you _must_ update the GUI on the main / UI thread, which is running at 60fps. But to answer the question... drawback is having to manage the whole 'this method must to be called on the audio thread, and that method must be called on the non-audio thread'. However this turns out to be little of a limitation since it is almost always what you want to do anyway, and you gain huge amounts in the area of responsiveness. In the end, every situation is different. With pd vanilla, audio is most important and maybe that deserves the current architecture. To me, it is more about keeping options open, which is why I think abstracting the visual position from the core is a good idea.___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
This one can be retriggered to change speed anytime. Ingo #N canvas 988 0 345 419 10; #X obj 71 135 random 128; #X obj 71 108 metro 5000; #X obj 71 90 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 189 line; #X obj 71 209 i; #X obj 71 162 pack f 5000; #X msg 254 32 5000; #X obj 161 384 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 365 5 0 0 0 - - -; #X obj 71 231 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 4400 1; #X floatatom 71 365 5 0 0 0 - - -; #X text 197 363 target; #X text 287 20 time; #X obj 14 73 loadbang; #X msg 253 10 1000; #X obj 181 69 t b f b; #X msg 134 19 0; #X msg 134 39 1; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 15 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 17 0; #X connect 15 1 1 1; #X connect 15 1 5 1; #X connect 15 2 16 0; #X connect 16 0 2 0; #X connect 17 0 2 0; > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von Ingo > Gesendet: Sonntag, 23. Februar 2014 04:21 > An: 'Roman Haefeli'; pd-list@iem.at > Betreff: Re: [PD] smooth random numbers > > Starting from Roman's patch I would probably do it like the attached > patch. > > Ingo > > > #N canvas 988 0 286 367 10; > #X obj 71 76 random 128; > #X obj 71 49 metro 5000; > #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; > #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg > 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 > 10 -262144 > -1 -1; > #X floatatom 161 306 5 0 0 0 - - -; > #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 > -1 -1 900 1; > #X floatatom 71 306 5 0 0 0 - - -; > #X text 197 304 target; > #X text 217 20 time; > #X obj 14 14 loadbang; > #X msg 183 10 1000; > #X connect 0 0 5 0; > #X connect 0 0 8 0; > #X connect 1 0 0 0; > #X connect 2 0 1 0; > #X connect 3 0 4 0; > #X connect 4 0 9 0; > #X connect 5 0 3 0; > #X connect 6 0 1 1; > #X connect 6 0 5 1; > #X connect 8 0 7 0; > #X connect 9 0 10 0; > #X connect 13 0 2 0; > #X connect 14 0 1 1; > #X connect 14 0 5 1; > > > > > -Ursprüngliche Nachricht- > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag > von > > Roman Haefeli > > Gesendet: Samstag, 22. Februar 2014 23:27 > > An: pd-list@iem.at > > Betreff: 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 988 0 345 419 10; #X obj 71 135 random 128; #X obj 71 108 metro 5000; #X obj 71 90 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 189 line; #X obj 71 209 i; #X obj 71 162 pack f 5000; #X msg 254 32 5000; #X obj 161 384 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 365 5 0 0 0 - - -; #X obj 71 231 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 4400 1; #X floatatom 71 365 5 0 0 0 - - -; #X text 197 363 target; #X text 287 20 time; #X obj 14 73 loadbang; #X msg 253 10 1000; #X obj 181 69 t b f b; #X msg 134 19 0; #X msg 134 39 1; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 15 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 17 0; #X connect 15 1 1 1; #X connect 15 1 5 1; #X connect 15 2 16 0; #X connect 16 0 2 0; #X connect 17 0 2 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
On Fri, Feb 21, 2014 at 3:54 AM, Jonathan Wilkes wrote: > On 02/20/2014 09:50 PM, Rich E wrote: > > > > On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes wrote: > >> On 02/18/2014 11:11 PM, Rich E wrote: >> >> >> >> >> On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox wrote: >> >>> Ah wait, duh. Of course the graph needs to know positioning, that's how >>> it determines execution order or independent blocks of objects right? >>> >>> On Jan 13, 2014, at 5:14 PM, Dan Wilcox wrote: >>> >>> Does the dsp graph rely on positioning? I thought only via connections. >>> I'd imagine the gui wrapper should only worry about positioning and simply >>> update those changes when saving. >>> >>> >>> >> >> IMO a separation between GUI and core could/would include position, >> e.g. objects have their connections mapped by an index, GUI assigns the >> index to the object based on position. This would allow for some much more >> sophisticated GUI's, such as 3d, or even a more human-readable text version >> (json has been mentioned). >> >> >> You run into problems when you want to get decent GUI interaction _and_ >> expect to deliver audio to the soundcard in realtime. >> >> > The GUI and audio shouldn't be updated from the same thread. This is > one nice thing about libpd, it forces a separation. > > > What are the drawbacks to the multi-threaded approach? Specifically, for > a full-fledged editing environment where you can't easily predict what the > userbase is going to come up with inside the GUI? > > > Firstly, I think the decision should at least be available (to process audio and GUI on separate threads), since this is the most common way to handle the two different update rates. Especially since, with most GUI frameworks, you _must_ update the GUI on the main / UI thread, which is running at 60fps. But to answer the question... drawback is having to manage the whole 'this method must to be called on the audio thread, and that method must be called on the non-audio thread'. However this turns out to be little of a limitation since it is almost always what you want to do anyway, and you gain huge amounts in the area of responsiveness. In the end, every situation is different. With pd vanilla, audio is most important and maybe that deserves the current architecture. To me, it is more about keeping options open, which is why I think abstracting the visual position from the core is a good idea. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Myo armband and Pd?
On 23/02/14 10:47, Richie Cyngler wrote: https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than "a set of predetermined gestures". Anyone else curious or have more info about this device? if they are saying "go away!" that loudly why would you be interested? Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] threads in pd, dataflow
On 23/02/14 15:13, Simon Wise wrote: Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree. ... but it is more an unroll than a break, or rather an exploration of the graph as a tree which may revisit the same nodes ... programmer beware of infinite loops, We can still create separate branches easily enough, if they overlap that is fine, the overlapping parts are simply included in each tree separately ... again programmer beware of the consequences and benefits of choosing a dataflow fanout rather than a trigger. It is in the dsp domain we make choices and break cycles in the graph by passing the data to the next block instead to allow loops to work as expected. Simon ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] threads in pd, dataflow
On 23/02/14 08:16, Jonathan Wilkes wrote: On 02/21/2014 10:04 PM, Simon Wise wrote: On 22/02/14 06:28, Jonathan Wilkes wrote: On 02/21/2014 06:41 AM, Simon Wise wrote: Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order. [...] Even the dsp<->gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. To know whether a control branch interacts with the signal domain is to solve the halting problem, no? especially not if you allow a little syntactical help from the programmer .. as you note here. And note the point of this is that generally the interaction with the dsp does not have to be in zero logical time after it is initiated, although often discrete sequences of interactions must be applied together in a single dsp timeslice. But also consider we are already making several simplifying assumptions and arbitrary (sometimes confusing) decisions as we turn the graph drawn as the pd patch into trees in the dsp and the message domains so that we can traverse them separately. If we allow fan-outs as parallel branches we change one of those arbitrary decisions. Instead of assigning an arbitrary order and re-writing the fan-out as a trigger we create new independent trees which we execute via a scheduler that runs in a similar way to any very basic OS scheduler ... when data is received for that tree it is put on a queue and executed the next time one of the cpu threads that pd has running is free. The usual priority queue stuff could be implemented regarding dsp interaction, scheduling on a basic level is very mundane stuff ... optimisations of all sorts at this point have been very well studied and can get as complex as you want. Note that we already break cycles in the graph, so we can indeed take each branch as a separate tree. There are obviously interesting complications and decisions regarding cold inlets, however the point of this is that by using a fan out the programmer is indicating that the branches may be run in parallel so cold inlets with data coming from outside should simply be updated whenever that data arrives ... use a trigger to ensure it is all part of the same tree if that is not good. But you could have some kind of "seal" object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way). It could look like a wax seal and always be at the top-left of the patch. that's somewhat like the notion in functional languages of 'pure' functions compared to ones with side effects, in this context the dsp could be considered as a side effect, in the same way any output from a functional program is ultimately a side effect. Each functional language deals with this differently, and they are useful in different contexts. Unless you get into seriously strange constructs like monads for output and remain a strictly pure language (lambda calculus is turing-complete after all) there is some syntactical way (like your wax seal) to flag non-pure objects. In pd the ~ naming convention already does this, and could be enforced by the interpreter. In pd the dsp and message passing domains are dealt with quite separately, and if we wanted to treat the message passing domain as a parallelisable dataflow graph with its effect on the dsp as one of its outputs (a side effect in functional languages jargon) then there is a wealth of research and implementations in the functional area to look into as a comparison. A very crucial point here is that separating gui from dsp so that gui calculations do not block dsp means allowing th
Re: [PD] smooth random numbers
Starting from Roman's patch I would probably do it like the attached patch. Ingo #N canvas 988 0 286 367 10; #X obj 71 76 random 128; #X obj 71 49 metro 5000; #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 306 5 0 0 0 - - -; #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 900 1; #X floatatom 71 306 5 0 0 0 - - -; #X text 197 304 target; #X text 217 20 time; #X obj 14 14 loadbang; #X msg 183 10 1000; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 1 1; #X connect 6 0 5 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 1 1; #X connect 14 0 5 1; > -Ursprüngliche Nachricht- > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von > Roman Haefeli > Gesendet: Samstag, 22. Februar 2014 23:27 > An: pd-list@iem.at > Betreff: 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 988 0 286 367 10; #X obj 71 76 random 128; #X obj 71 49 metro 5000; #X obj 71 31 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 71 130 line; #X obj 71 150 i; #X obj 71 103 pack f 5000; #X msg 184 32 5000; #X obj 161 325 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X floatatom 161 306 5 0 0 0 - - -; #X obj 71 172 vsl 15 128 0 127 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 900 1; #X floatatom 71 306 5 0 0 0 - - -; #X text 197 304 target; #X text 217 20 time; #X obj 14 14 loadbang; #X msg 183 10 1000; #X connect 0 0 5 0; #X connect 0 0 8 0; #X connect 1 0 0 0; #X connect 2 0 1 0; #X connect 3 0 4 0; #X connect 4 0 9 0; #X connect 5 0 3 0; #X connect 6 0 1 1; #X connect 6 0 5 1; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 13 0 2 0; #X connect 14 0 1 1; #X connect 14 0 5 1; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] Myo armband and Pd?
https://www.thalmic.com/en/myo/ Is anyone working with this? Unfortunately it's closed source and their locking down the data stream from what I've read. I actually can't find what sort of data it does put out other than "a set of predetermined gestures". Anyone else curious or have more info about this device? -- Richie www.glitchpop.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] smooth random numbers
On 2014-02-22 16:54, Pagano, Patrick wrote: Hello i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number? One way is to do a random walk, where you would start with 64 and then add one if random(128) is greater than 63 or subtract one if it's less. (or add zero for some deadband around 63). You could use a constant sample rate or vary that as well with random delays between samples. Random walks tend to walk outside the range so you also need a way to bring it back when it crosses a boundary (0 or 127). Martin ___ 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
Re: [PD] smooth random numbers
I guess you should just use [line] and make sure the line time is equal or just a bit shorter than the object you use to ask random for a new number. -- Lic. José Rafael Subía Valdez www.jrsv.net > On 22/02/2014, at 16:54, "Pagano, Patrick" wrote: > > Hello > > i have asked this is a few different ways and experimented but i am > wondering, how does one create "smooth random" numbers that flow between each > number instead of hoping from number to number? > > 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. > > 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 > > thank you > > Patrick > > > 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
[PD] smooth random numbers
Hello i have asked this is a few different ways and experimented but i am wondering, how does one create "smooth random" numbers that flow between each number instead of hoping from number to number? 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. 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 thank you Patrick 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
Re: [PD] threads in pd, dataflow
On 02/21/2014 10:04 PM, Simon Wise wrote: On 22/02/14 06:28, Jonathan Wilkes wrote: On 02/21/2014 06:41 AM, Simon Wise wrote: Something to really make pd parallel would involve treating fan-outs as opportunities for the interpreter to launch each branch in a new thread, implementing the inherent parallelism in the dataflow paradigm (e.g. in the pd definition of fan-outs as being executed in undefined order). Here the trigger object is used to force sequential execution where required, just as it is now. Practically speaking, it's completely different for control than for signal domain. For signal domain fanouts there's an understanding that Pd gets stuff done when it needs to get done. In the control domain, there's even a philosophy of _never_ having fanouts at all. I don't know what the effect would be of trying to auto-parallellize a signal diagram, but I'm pretty sure trying to auto-parallellize a control diagram wouldn't make much of a dent. I was referring to parallelising using control fanouts only, but didn't make that clear. 'No fanouts, always use triggers' is a very sensible policy to avoid easily overlooked bugs when, as in pd, fanouts are just an implied trigger with an undefined order. [...] Even the dsp<->gui problem would be addressed by a proper dataflow implementation if it was done well. Keeping all the gui stuff in branches which don't have ~ objects should result in these branches being separate threads, and well implemented these would not be allowed to block ~ branches. To know whether a control branch interacts with the signal domain is to solve the halting problem, no? But you could have some kind of "seal" object that verifies the user thinks a subpatch or canvas is 100% pure control domain. And then Pd could take that to mean throw it in its own thread (and throw warnings/errors if it finds a message going to a signal object, or fudging with dsp in any way). It could look like a wax seal and always be at the top-left of the patch. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] core <-> gui question
Hi list, I've got a nice little method for an info class in Pd-l2ork that tells whether an x/y coordinate lies within an object on a particular canvas. For the new svg-style drawing commands I've added, this method makes it possible to do some fairly simple tests within a patch to make sure I don't break things along the way. For example, I can check the bbox of scalars that contain transformed shapes, or check to make sure that the stroke-width is contained within the bbox, check positions of gop scalars, nested data structures, etc. If the gui and core were truly separated, how would I do these tests within Pd? To follow the Pd message-passing model, I need to get an answer to my query in zero logical time. If the bbox data is only held by the gui then I have to send a request over the socket, and the object chain will have finished computing before the gui sends back its data. If the core holds a synced copy of bbox data then the gui must either a) constantly bombard it with updated values or b) send a message that tells the core what got updated and let the core update data for all relevant objects. In which case there's no longer really a separation between gui and core. On a related note-- for the new drawing commands I'm doing all kinds of crazy calculations in the core for stuff like getting the bbox of an svg path. It's ridiculous because all that math has already happened in Tkpath, but I can cache it so Pd doesn't take a huge performance hit. But I simply couldn't figure out a way to get that data from the gui in a way that doesn't cause all kinds of syncronization problems. By the time *_getrect is called the core must already have the bbox data, otherwise it's too late. Is there some way to deal with that without moving the entire gui logic out of the core? I couldn't think of one. -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ps3 controller under linux
On 02/22/2014 07:22 PM, Charles Goyard wrote: The help patch says you can open by vendor and product id. Thanks. I already tried that, but forgot to prepend the 0x. Using [open 0x054c 0x0268( works just great! Sorry about that :-) -- Atte http://atte.dk http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ps3 controller under linux
Hi, Atte wrote: > Ok, after sending the mail, I did some further poking, and it seems [open > 10] opens the controller. > > Using device 10 seems like a bad idea to me (I might be wrong), since I'd > expect that device number to depend on what else is plugged in and in what > order. Is there a better way? The help patch says you can open by vendor and product id. Enjoy, ++ -- Charles ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] ps3 controller under linux
On 02/22/2014 06:54 PM, Atte wrote:
On 02/22/2014 06:33 PM, Atte wrote:
it seems
[open 10] opens the controller.
I mean "[open 10(" of course :-)
--
Atte
http://atte.dk http://modlys.dk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] ps3 controller under linux
On 02/22/2014 06:33 PM, Atte wrote: So I'm hoping someone could give a hint or suggestion about what to try next, things I could have forgotten etc. Ok, after sending the mail, I did some further poking, and it seems [open 10] opens the controller. atte@skagen:~$ ll /dev/input/ total 0 drwxr-xr-x 2 root root 240 Feb 22 18:14 by-id drwxr-xr-x 2 root root 220 Feb 22 18:14 by-path crw--- 1 root root 13, 64 Feb 22 11:31 event0 crw--- 1 root root 13, 65 Feb 22 11:31 event1 crw-rw+ 1 root root 13, 74 Feb 22 18:14 event10 crw--- 1 root root 13, 66 Feb 22 11:31 event2 crw--- 1 root root 13, 67 Feb 22 11:31 event3 crw--- 1 root root 13, 68 Feb 22 11:31 event4 crw--- 1 root root 13, 69 Feb 22 11:31 event5 crw--- 1 root root 13, 70 Feb 22 11:31 event6 crw--- 1 root root 13, 71 Feb 22 11:31 event7 crw--- 1 root root 13, 72 Feb 22 11:31 event8 crw-rw-r-T 1 root video 13, 73 Feb 22 11:31 event9 crw-rw-r-T+ 1 root root 13, 0 Feb 22 18:14 js0 crw--- 1 root root 13, 63 Feb 22 11:31 mice crw--- 1 root root 13, 32 Feb 22 11:31 mouse0 crw--- 1 root root 13, 33 Feb 22 11:31 mouse1 crw--- 1 root root 13, 34 Feb 22 11:31 mouse2 Using device 10 seems like a bad idea to me (I might be wrong), since I'd expect that device number to depend on what else is plugged in and in what order. Is there a better way? Regards -- Atte http://atte.dk http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] ps3 controller under linux
Hi I'm trying to get the input from a ps3 controller into PD. In the end I'd like to have it connect wireless, but for now I just connected via usb and tapped the PlayStation button on the controller. This shows up in lsusb: atte@skagen:~$ lsusb | grep Sony Bus 003 Device 013: ID 054c:0268 Sony Corp. Batoh Device / PlayStation 3 Controller "cat /dev/input/js0" (as regular user) show the expected garbage when moving the controller around or touching buttons. I also get input in chuck opened with Hid.openJoystick(0), so I'm pretty sure the controller is recognized and sending stuff into the system. In PD I trued using [hid] and sending [open ( with just about everything I could think of. So I'm hoping someone could give a hint or suggestion about what to try next, things I could have forgotten etc. Regards -- Atte http://atte.dk http://modlys.dk ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
