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, [email protected] wrote:
> 
> Send Pd-list mailing list submissions to
>       [email protected]
> 
> 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
>       [email protected]
> 
> You can reach the person managing the list at
>       [email protected]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pd-list digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: buffer and performance woes on OSX (Jesse Mejia)
>   2. Re: Dynamic Patching with 0.47 (Thomas Mayer)
>   3. A 6th order hilbert transformer? (Alexandre Torres Porres)
>   4. 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 <[email protected]>
> To: Alex <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [PD] buffer and performance woes on OSX
> Message-ID: <[email protected]>
> 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 <[email protected]> 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 <[email protected] 
>> <mailto:[email protected]>> 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
>> _______________________________________________
>> [email protected] <mailto:[email protected]> mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list 
>> <https://lists.puredata.info/listinfo/pd-list>
>> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20160621/f073810c/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 22 Jun 2016 02:24:20 +0200
> From: Thomas Mayer <[email protected]>
> To: [email protected]
> Subject: Re: [PD] Dynamic Patching with 0.47
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=utf-8
> 
> Hi,
> 
> On 20.06.2016 09:29, IOhannes m zmoelnig wrote:
>> On 2016-06-20 03:38, Miller Puckette wrote:
>>> (I keep wanting to make some sort of "delete" message to canvases
>>> but can't figure out what would be a usable design).
>> 
>> what's wrong with the index that can be found everywhere else? e.g.
>> iemguts adds a "delete" message (to the canvas) that takes a
>> single number: 
>> https://git.iem.at/pd/iemguts/blob/master/src/canvasdelete.c
>> 
>> (actually it takes a list of numbers, but i've never used that).
>> 
>> so using "delete <index>" whould be: - consistent with the current
>> user-interface (e.g. "connect") - backward compatible with prior
>> implementations
> 
> Thanks, [delete( from iemguts' [canvasdelete] is just what I needed,
> and makes it even clearer.
> 
> cu Thomas
> -- 
> "Anything can be a tool - poverty, war. War is useful because it
> is effective in so many areas." (Bijaz to Hayt in: Frank Herbert -
> Dune Messiah)
> http://www.residuum.org/
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 21 Jun 2016 23:37:59 -0300
> From: Alexandre Torres Porres <[email protected]>
> To: "[email protected]" <[email protected]>
> Subject: [PD] A 6th order hilbert transformer?
> Message-ID:
>       <CAEAsFmg+PG=-jb5jtg-n7etzsr6mgcemapvskk0cs7b9wwa...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Howdy, I'm working on a frequency shifter object (via single sideband
> modulation / complex modulation).
> 
> In Max they have a so called "6th order hilbert transformer with a minimum
> of error". In Pd, the hilbert~ abstraction is 4th order. I'm copying the pd
> abstraction for now, but I was hoping to use such a higher order filter and
> also use- but I can't find a source for such a formula. Any help finding it?
> 
> thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.puredata.info/pipermail/pd-list/attachments/20160621/a4d95cf2/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 21 Jun 2016 23:50:05 -0700
> From: Derek Kwan <[email protected]>
> To: Jack <[email protected]>
> Cc: [email protected]
> Subject: Re: [PD] Best way to install Pd on Raspberry Pi
> Message-ID: <20160622065005.GA5858@dxk-xps15>
> Content-Type: text/plain; charset=us-ascii
> 
> hello,
> 
> you should move the pd binary to /usr/local/bin/
> 
> That directory should already be in your PATH and typically binaries any
> user can run are put there (if you make install from source, it goes
> there as well).
> 
> Once you've moved the pd binary to /usr/local/bin, you can type pd not
> matter what directory you're in and it'll run.
> 
> Derek
> 
>> Yep,
>> 
>> Raspberry Pi 3
>> Raspbian Jessie
>> ++
>> 
>> Jack
>> 
> =====================
> Derek Kwan
> www.derekxkwan.com
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Pd-list mailing list
> [email protected]
> to manage your subscription (including un-subscription) see
> https://lists.puredata.info/listinfo/pd-list
> 
> 
> ------------------------------
> 
> End of Pd-list Digest, Vol 135, Issue 78
> ****************************************


_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to