Hi list,
I want to create a GUI using several filledpolygon instances. How can I capture which polygon has been clicked?
Thanks!
Julian.
On Jun 22, 2016, at 19:00 PM, pd-list-request@lists.iem.at wrote:
Send Pd-list mailing list submissions to pd-list@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit https://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request@lists.iem.at
You can reach the person managing the list at pd-list-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..."
Today's Topics:
- Re: buffer and performance woes on OSX (Jesse Mejia)
- Re: Dynamic Patching with 0.47 (Thomas Mayer)
- A 6th order hilbert transformer? (Alexandre Torres Porres)
- Re: Best way to install Pd on Raspberry Pi (Derek Kwan)
Message: 1 Date: Tue, 21 Jun 2016 15:43:49 -0700 From: Jesse Mejia jmejia@anestheticaudio.com To: Alex x37v.alex@gmail.com Cc: "pd-list@lists.iem.at" Pd-list@lists.iem.at Subject: Re: [PD] buffer and performance woes on OSX Message-ID: 03F0DE45-AA73-4723-A51E-D079A16F449D@anestheticaudio.com Content-Type: text/plain; charset="utf-8"
Thanks! Moving the midi out to a separate patch - in a separate instance. (from a copy/pasted pd application) solved my problems. I’m sending OSC between the two patches and everything is smooth.
But I still wonder if there’s a way to do this from within one instance. Pd~ seems to only separate the dsp processes - but my problem was actually with midi output. It would be great if there’s a way to prioritize and/or specificy threading for abstractions.
-Jesse
On Jun 21, 2016, at 2:37 PM, Alex x37v.alex@gmail.com wrote:
If the audio logic is exclusively dependent on the midi input and the midi output is also exclusively dependent on the midi input you could potentially separate the midi output into its own process and run it independently of the audio?
If they're instead both dependent on some processed version of the midi, but not on each-other, you could do the processing in one of the processes then still generate your audio/midi out independently.
-Alex
On Tue, Jun 21, 2016 at 1:51 PM, Jesse Mejia <jmejia@anestheticaudio.com mailto:jmejia@anestheticaudio.com> wrote: Hi list,
I’m having some performance problems - clicks/dropouts when I feed my patch too much note concurrency by way of midi input into some [clone]d karplus strong abstractions among other things - but only when I’m concurrently sending midi out.
I’m finding that the audio settings menu hangs PD depending on what buffer size I choose. I’m only able to choose 64 or 128.
Typically I would increase buffer size to compensate - but the only other buffer setting that doesn’t hang pd is 128 and it actually gives me even more dropouts. I’ve tried playing around with block~ but couldn’t really get that helping either.
'defeat real-time scheduling' seems to help things somewhat. and running -rt didn’t seem to do anything either way. -nogui also didn’t help
I’m using a fairly unimpressive 2-core mac mini.. and I do have about 1/2 of my DSP running in a pd~ instance so maybe I just need to run this on a more powerful machine.
I’m sending a fair amount of midi data via ctlout to some micro controllers. Basically the more note-ins my patch receives - the more ctlout data it sends. Removing that part of the patch makes the dsp blocking clicks go away - but it seems like the midi out shouldn’t be interfering with audio so much. Is there a way to make PD prioritize the audio over the midi output? It would be great if I could wrap the midi output stuff in a lower priority abstraction somehow… I don’t think pd~ helps me there because there isn’t actually any DSP in the midi output abstraction - just control data...
OSX 10.11.1 (el capitan) Pd 0.47.1 Motu 24AO (though it was experiencing audio blocking and also lock ups on the audio settings panel w/ the internal interface as well)
Any tips?
-Jesse _______________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
hello,
in help browser/4.datastructure/08.selection.pd we can see how to bind scalars, this help patch is designed to give a scalar pointer from right click selected scalar, and you can have pointer from scalar left click or on scalar change by modifying the route object in [pd template8], look at the console...
The scalar can be handled with [get] and [set] from pointer given by
[struct] object when the scalar is clicked.
patko
Le 23/06/2016 à 04:04, Julián Villegas a écrit :
Hi list,
I want to create a GUI using several filledpolygon instances. How can I capture which polygon has been clicked?
Thanks!
Julian.
On Jun 22, 2016, at 19:00 PM, pd-list-request@lists.iem.at wrote:
Send Pd-list mailing list submissions to pd-list@lists.iem.at
To subscribe or unsubscribe via the World Wide Web, visit https://lists.puredata.info/listinfo/pd-list or, via email, send a message with subject or body 'help' to pd-list-request@lists.iem.at
You can reach the person managing the list at pd-list-owner@lists.iem.at
When replying, please edit your Subject line so it is more specific than "Re: Contents of Pd-list digest..."
Today's Topics:
- Re: buffer and performance woes on OSX (Jesse Mejia)
- Re: Dynamic Patching with 0.47 (Thomas Mayer)
- A 6th order hilbert transformer? (Alexandre Torres Porres)
- Re: Best way to install Pd on Raspberry Pi (Derek Kwan)
Message: 1 Date: Tue, 21 Jun 2016 15:43:49 -0700 From: Jesse Mejia jmejia@anestheticaudio.com To: Alex x37v.alex@gmail.com Cc: "pd-list@lists.iem.at" Pd-list@lists.iem.at Subject: Re: [PD] buffer and performance woes on OSX Message-ID: 03F0DE45-AA73-4723-A51E-D079A16F449D@anestheticaudio.com Content-Type: text/plain; charset="utf-8"
Thanks! Moving the midi out to a separate patch - in a separate instance. (from a copy/pasted pd application) solved my problems. I’m sending OSC between the two patches and everything is smooth.
But I still wonder if there’s a way to do this from within one instance. Pd~ seems to only separate the dsp processes - but my problem was actually with midi output. It would be great if there’s a way to prioritize and/or specificy threading for abstractions.
-Jesse
On Jun 21, 2016, at 2:37 PM, Alex x37v.alex@gmail.com wrote:
If the audio logic is exclusively dependent on the midi input and the midi output is also exclusively dependent on the midi input you could potentially separate the midi output into its own process and run it independently of the audio?
If they're instead both dependent on some processed version of the midi, but not on each-other, you could do the processing in one of the processes then still generate your audio/midi out independently.
-Alex
On Tue, Jun 21, 2016 at 1:51 PM, Jesse Mejia <jmejia@anestheticaudio.com mailto:jmejia@anestheticaudio.com> wrote: Hi list,
I’m having some performance problems - clicks/dropouts when I feed my patch too much note concurrency by way of midi input into some [clone]d karplus strong abstractions among other things - but only when I’m concurrently sending midi out.
I’m finding that the audio settings menu hangs PD depending on what buffer size I choose. I’m only able to choose 64 or 128.
Typically I would increase buffer size to compensate - but the only other buffer setting that doesn’t hang pd is 128 and it actually gives me even more dropouts. I’ve tried playing around with block~ but couldn’t really get that helping either.
'defeat real-time scheduling' seems to help things somewhat. and running -rt didn’t seem to do anything either way. -nogui also didn’t help
I’m using a fairly unimpressive 2-core mac mini.. and I do have about 1/2 of my DSP running in a pd~ instance so maybe I just need to run this on a more powerful machine.
I’m sending a fair amount of midi data via ctlout to some micro controllers. Basically the more note-ins my patch receives - the more ctlout data it sends. Removing that part of the patch makes the dsp blocking clicks go away - but it seems like the midi out shouldn’t be interfering with audio so much. Is there a way to make PD prioritize the audio over the midi output? It would be great if I could wrap the midi output stuff in a lower priority abstraction somehow… I don’t think pd~ helps me there because there isn’t actually any DSP in the midi output abstraction - just control data...
OSX 10.11.1 (el capitan) Pd 0.47.1 Motu 24AO (though it was experiencing audio blocking and also lock ups on the audio settings panel w/ the internal interface as well)
Any tips?
-Jesse _______________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
-
Julián Villegas -
patrice colet