PdParty
PdParty copied to clipboard
danomatika
multitouch on canvas
Multitouch on canvas unfortunately doesn't work. I use a canvas to design a background. On canvas the touch function just sends on finger.
The canvas widget inherits single-touch form the main Widget class. It just needs to have multi-touch handling added to it like the patch canvas background.
is it complicated to realize?
I have also another suggestion:
When I touch for example widgets and continue to move on with the finger, it stops to sending the xy-position. It could be nice to get the xy-data to change the position of a widget for example.
I am following the idea of the implementation in Slice//Jockey to change the positions of radiobuttons and use the values of the position for other reasons.
The touch view event handling basically finds the lowest subview in the tree to send the touch event too, however it could also send the global touch from the patch canvas background level. Then the touch events would register everywhere, ie. like cyclone [mouseState] etc. I assume that's what you are requesting?
exactly! A delta value like in mouseState would be also practically. I tried to implement with pd, but I acutally dont understand completely how [mouseState] samples the delta postions.
Mmm it wouldn't be a delta value, but the basic position for each touch, uninterrupted by widgets. This could be a setting that could be enabled to get full xy over the screen instead of stopping once entering a widget.
The idea with the current implementation is that you don't automatically get a mix so you can have one behavior to the main patch background and another with the GUI widgets without getting both at once. Your original suggestion of canvas handling multi-touch would also make it easier to, for instance, separate interaction spaces.
OTOH I prefer to match the behavior in PdParty with that of desktop Pd as the UI is a reimplementation. The overall goal is to replace the custom event handling with Pd's internal GUI and event handling once we have appropriate abstractions.
If I understand you right, a general globaltouch event would fit to your idea?
I have a way to make this work. Should it be always sending touch events even when over a GUI object or should it be selectable: on - send always, off - send when not over an interactive widget? I am thinking it would be annoying to have a touch synth that also makes sound when you are adjusting a slider. For more advanced usages like moving cnv or other objects around, I think it makes sense to toggle on sending everything, then toggle it off afterwards.
@Ant1r @chr15m Does droidparty support touch events in general? I know of the [touch] xy abstraction, I mean canvas-wide touch handling? If so, I want to make sure to match the handling so porting projects between DroidParty and PdParty is easier.
No I had a quick grep through the code and I don't think PdDroidParty detects any kind of global touch event.
Well all is in the code:
-
the Widget class defines "virtual" touch up/down/move methods; arguments are
(pointer_id, pointer_x, pointer_y): https://github.com/chr15m/PdDroidParty/blob/bdbe758fdd3a2cf846b15efcab48e49a764d5505/src/cx/mccormick/pddroidparty/Widget.java#L233-L244 -
The "PatchView" forwards touch events to every widget: https://github.com/chr15m/PdDroidParty/blob/bdbe758fdd3a2cf846b15efcab48e49a764d5505/src/cx/mccormick/pddroidparty/PdDroidPatchView.java#L154-L188
-
Each widget processes the event in this way:
- if the event is "touch down" and is inside the widget bounding box, then the widget memorizes the pointer_id to a private member
pid0, and itstouchdown()callback returnstrueto tell PatchView to stop forwarding the event to other widgets (the event has been "captured"). - on "touch up", if the pointer_id is equal to
pid0thenpid0is set to -1 (the widget "forgets" this pointer id). - on "touch move", if pointer_id is equal to
pid0, the widget'stouchmove()callback processes the move and returnstrue.
See slider implementation: https://github.com/chr15m/PdDroidParty/blob/bdbe758fdd3a2cf846b15efcab48e49a764d5505/src/cx/mccormick/pddroidparty/Slider.java#L137-L178
Shorter answer: yes, PdDroidParty processes touch events by using the Android interface "OnTouchListener" (see https://developer.android.com/reference/android/view/View.OnTouchListener).
But do touch events over widgets end with the widget or are they also forwarded to the patch via #touch? From what you’ve, written it seems to stop with the widget.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Nov 29, 2022, at 11:21 AM, Antoine Rousseau @.***> wrote:
Shorter answer: yes, PdDroidParty processes touch events by using the Android interface "OnTouchListener" (see https://developer.android.com/reference/android/view/View.OnTouchListener).
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
Ah OK, so no, PdDroidParty doesn't forward touch events to #touch. It should be easy to implement if wanted. In this case PdDroidParty will have to mimic PdParty, which implemented it first.
Actually RjDj implemented it first and PdParty provides the same compatible events, by default.
My question is relates to behavior: should #touch receive only those touches not on a widget or should it report all touch irregardless of what is there, ie. like cyclone [mousestate]? I’m leaning towards the latter since desktop Pd is not widget-aware in this regard. My preference is to try to match desktop Pd’s behavior, when possible.
enohp ym morf tnes
Dan Wilcox danomatika.com robotcowboy.com
On Nov 29, 2022, at 12:17 PM, Antoine Rousseau @.***> wrote:
Ah OK, so no, PdDroidParty doesn't forward touch events to #touch. It should be easy to implement if wanted. In this case PdDroidParty will have to mimic PdParty, which implemented it first.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.
I think unconditional forwarding is OK, even if it could cause problems sometimes. IMO a "touch" widget (that could be multi-touch aware) is a better way to implement a freestyle touch management anyway.
DroidParty has a Touch widget already, but it is single-touch aware. We could introduce a MultiTouch variant which outputs a list in the same format as #touch: id type x y
On Nov 29, 2022, at 4:58 PM, Antoine Rousseau @.***> wrote:
I think unconditional forwarding is OK, even if it could cause problems sometimes. IMO a "touch" widget (that could be multi-touch aware) is a better way to implement a freestyle touch management anyway.
— Reply to this email directly, view it on GitHub https://github.com/danomatika/PdParty/issues/79#issuecomment-1330869798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADVK7KY3Z6HPUAQAZRSLKTWKYR2VANCNFSM4T3FKLNA. You are receiving this because you commented.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
This is probably better in another issue, but I'd suggest DroidParty implements the minimum RjDj-style events: #touch, #accelerate, #gyro. The rest may/may not be iOS-specific: https://github.com/danomatika/PdParty/blob/master/doc/guide/PdParty_User_Guide.md#events
UPDATE: Ah, I see Chris already has issues for this on the PdDroidParty Github repo.
Back to the original topic: I have this working now but decided to leave it off by default. There is new behavior, however, where canvas and comments forward touch events always and I think this gets to the heart of the issue at hand.
Additionally, touch sending for "everywhere" aka on all widgets can be enabled via sending #pdparty touch everywhere 1.
This features are now in the PdParty 1.3.0 beta6 build.
Please join the 1.3.0 beta until I can make a proper release. Install the free TestFlight app on your iDevice, then open this TestFlight link:
https://testflight.apple.com/join/17ZZ5AC7