What will be provided in Pd (if any of this) is up to Miller of
course. The current discussion explores implementation options and
challenges. [mousestate] in mode 1 ('patch relative') comes close to
'GOP-relative' mouse tracking as proposed by Christof Ressi earlier in
this thread.
Unfortunately
Hi, the concepts of [mousestate] and [mousepad] are different, they
complement each other. [mousepad] is a widget, like slider & Co. If
they are stacked, only one at a time can have mouse focus.
[mousestate] doesn't steal mouse focus of widgets above it. Both
concepts have their own use cases.
Em qui, 21 de mar de 2019 às 06:18, Lucas Cordiviola
escreveu:
> [cyclone/mousestate] is very raw compared to [mousepad]. You can have one
> or more [cyclone/mousestate] and they all will just output the same xy
> coords for the screen (not the patch).
>
actually there are 3 modes of operation
On 3/21/2019 6:18 AM, Lucas Cordiviola wrote:
> You can have one or more [cyclone/mousestate] and they all will just
> output the same xy coords for the screen (not the patch).
I meant many [mousestate] in different opened patches.
Mensaje telepatico asistido por maquinas.
[cyclone/mousestate] is very raw compared to [mousepad]. You can have one or
more [cyclone/mousestate] and they all will just output the same xy coords for
the screen (not the patch).
Probably is very easy for [mousepad] to incorporate an option like "global
sender" to give the same
I love the idea of a native 2d slider, but how about providing the same
functionality from [cyclone/mousestate]?
Em qui, 21 de mar de 2019 às 01:47, Chris McCormick
escreveu:
> On 19/3/19 11:17 pm, katja wrote:
> > Mousepad code is up for inspection at:
> >
> >
On 19/3/19 11:17 pm, katja wrote:
Mousepad code is up for inspection at:
https://github.com/katjav/pd-mouse-trial
This is great!
Cheers,
Chris.
--
https://mccormick.cx/
My tech development newsletter:
https://mccormick.cx/subscribe
___
Pd-dev
Hi Katja, et al
Just tried this in Mojave, it works really nice!
I just made an issue with a bit more info:
https://github.com/katjav/pd-mouse-trial/issues/1
Hope it helps!
fede
On Tue, Mar 19, 2019 at 4:19 PM katja wrote:
> Mousepad code is up for inspection at:
>
>
Mousepad code is up for inspection at:
https://github.com/katjav/pd-mouse-trial
So far it was built on Linux and tested with Pd 0.48 and 0.49, not
sure if it will work right away on other platforms.
The implementation is unconventional; it doesn't use the iemgui
framework and replaces Tk
Hi,
On 18/3/19 12:31 am, Christof Ressi wrote:
personally I would prefer 2), simply because it allows you to build custom
widgets as Pd abstractions. a tracking area can be built quite easily with GOP.
Mouseup is a bit of a maverick: you want to be alerted regardless of
mouse position, i.e.
Hi,
On 17/3/19 11:38 pm, katja wrote:
Mouseup is a bit of a maverick: you want to be alerted regardless of
mouse position, i.e. any canvas or even outside Pd's territory.
Otherwise one could easily get the equivalent of a dangling midinote.
Therefore, would it be reasonable to conceive a
A precursor of this code can be found at
https://github.com/electrickery/pd-playground/tree/master/GUI in the
GUI5.c and GUI6.c objects.
Greetings,
Fred Jan
On 17/03/2019 22.27, katja wrote:
Dan, the code isn't published but could be shared somewhere for the
purpose of discussion if that is
Dan, the code isn't published but could be shared somewhere for the
purpose of discussion if that is useful. Not sure what is a good
place.
Frankly I've spent quite some time investigating the subject and my
conclusion is: it is not at all self-evident what a mouse class should
do exactly, even
Katja: Do you have some sample code using this implementation? I've not looked
into this in depth yet.
> On Mar 17, 2019, at 4:38 PM, katja wrote:
>
> Eventually the widget won my preference because it is easier to use,
> and because Pd's widgetbehavior infrastructure is made for such things
>
rrent cursor position? the
second could be handy for drop funtionality. maybe this could be
controlled by a creation argument/flag.
Christof
> Gesendet: Sonntag, 17. März 2019 um 16:38 Uhr
> Von: "katja"
> An: "Christof Ressi"
> Cc: pd-dev , "Dan Wilcox
ut loud.
>
> Christof
>
> Gesendet: Sonntag, 17. März 2019 um 16:07 Uhr
> Von: "Christof Ressi"
> An: "Dan Wilcox"
> Cc: pd-dev
> Betreff: Re: [PD-dev] local canvas-only pd_bind
> personally, I like the mechanism of [iemguts/receivecanvas] where you
&
the location within you patch structure, e.g. you can put it in a subpatch and you just have to increase the parent level by 1.
Christof
Gesendet: Sonntag, 17. März 2019 um 14:28 Uhr
Von: "Dan Wilcox"
An: "Christof Ressi"
Cc: pd-dev , "Chris McCormick"
Betreff:
Some good ideas.
I agree that GOP is basically a natural analogy to a tracking area already, so
that might be a good place to look. Perhaps this can be rolled into the name
canvas mechanism whereby a named canvas will receive mouse events when GOP is
enabled?
> Hi Dan, thanks for looking into
would be nice (in the past, people have faked this by putting other GUI objects below the canvas, but it's really clumsy).
Christof
Gesendet: Sonntag, 17. März 2019 um 13:38 Uhr
Von: "Dan Wilcox"
An: "Chris McCormick"
Cc: pd-dev
Betreff: Re: [PD-dev] local canvas-o
That's a similar concept to Cocoa's NSTrackingArea. It's basically a rectangle
in a view that you attach which then receives mouse enter, leave, move, down,
up, & drag events. You can update the position and size whenever.
20 matches
Mail list logo
