Inspired from whale-av i started to build a .tcl mouse plug-in.
I need to put the .tcl file into my "extra" folder, somehow it doesnt work with the declare object. Right now i get the mouse coordinates of a defined canvas, it would be nice to switch between different canvases and not to get any coordinates if i click outside of the canvas. I know that there are already some libraries that can handle mouse tracking, i just wanted to find out whats possible and learn a little bit about .tcl. Heres the test patch and the plugin: mouse_coordinates_plugin_test_4.zip
Experimental Mouse Plugin
Inspired from whale-av i started to build a .tcl mouse plug-in.
Is there something like the declare object for plugins, so that i can load a plugin from a patch? Another question is if its possible not to get error messages ("no such object") if theres no "motion" "mouseup" or "mousedown" receive object in the pd patch. the plugin sends the mouse coordinates with pdsend to those receives.
@Jona Yes... plugins need to be in a path found at Pd startup...... I have mine in a dedicated folder on my desktop so that I can easily swap them out as required, and the path set in Pd startup (libs).
You can get the window name........ mouse.zip
I have been working hard on a show, and now it's time to do my tax returns..... but I have thought about it a little.
I think the only way to do what you want is to is to filter by the window name.
.... pattern match the name on the first click to a window.......... store the name on the first click..... protect it.... and spigot the mouse data received when the window name matches. If the window name is dripped, the last 3 characters are always? numerals, and [==] could be used. If you want to use the whole name then I remember that there were externals in extended that would do the job, but that is not ideal.
.... place a receive object with the window name as its argument in the patch......sent by the plugin.... but only once. It can be done I am sure. Here is some stuff I worked on earlier that contains some ideas........ pop.zip
Thanks David, very helpful. mouse.zip and pop.zip works for me, the send_back_noerr-plugin.tcl somehow not, i will try to understand and find the error. Good idea with the window name. Thanks also for the link to the tcl.tk documentation, i have to admit that i am really new to it and to programming in general (besides pd). Success with your show.
with windows you could also use a batch file to start pd, add a path to a folder containing the mouseup-plugin.tcl and then open the patch that contains the [r mouseup]
cd "C:\Program Files (x86)\Pd\bin"
pd -path ..\extra\tclmouse-folder -open ~\Desktop\test-folder\mouse-test.pd
Sorry, you will have to modify the plug-in to get motion etc. again.... or rather modify your plugin to get "mouse_receive $focused_window" into the pdsend message.
The problem that took time to solve is that the [mouse_receive] object could have outlets, but they would have to be reconnected at every creation, as the creation argument is different every time.......
Some dynamic connections could be built in, but predicting the object numbers might not work.
A bit complex. It works but it would be good to auto destroy the [mouse_receive] object before saving the patch. It can stay, but after a while the patch might get large, and the same .xwindow reference might come up?
The help file (and therefore a patch) can be opened many times and the mouse messages will remain separate, but the [mouse_receive] abstraction must be created before opening the next [mouse_receive-help] patch or the $0 values will be wrong...... so it will be best to connect the [loadbang]....
I just left it disconnected to show the build.
@david thanks for your patch and the advices, it helped a lot. i realized that i need sys_gui from the hcs library for the patch. but no success with the "no err plugin" so far. @balwyn thanks for the tip with the .bat file. heres a new version of the patch and the plugin, its based on the "focused mouse receive" patch. You can open several pd windows and you should get the mouse coordinates for mouseup, motion and mousedown only in the selected window, and it loads the dynamic mouse_receive objects with loadbang (they need quite a long delay time if you start pd from the patch). In tcl is also a "bind all <FocusIn><FocusOut>" function which sends something if a new window is in focus, but i couldnt make use of it: mouse_coordinates_plugin_test_5.zip
now the patch is vanilla, it works without the sys_gui object and without the mouse_receive abstraction. i do use the <FocusIn> tcl. function now. the "no err plugin" problem is still not solved, but quiet satisfied so far. would be nice to tell the .tcl file something like " if the mouse_receive object exists then.... else..." . would also be nice to track the mouse only in pd runmode. does anybody know if there is something like $focused_cancas instead of $focused_window for the plugin code? you need to update the experimental mouse plugin to make it work, its much simpler now: mouse_coordinates_plugin_test_7c.zip (updated again)
thats what i found out: experimental_mouse_plugin_7g.zip its kind of a hack with canvas position. i think its not possible to have a satisfying mouse tracking without the use of externals. externals are also better than the plugin solution because i can use declare and can load them from the patch. the best external for that, that i found so far is iem_event from iem_gui, strangely in the iem_event-help file i had to rename iem_ivnt into iem_event to make it work. i have a more general question: does anybody know why i dont get every float if i track a regular number box with the mouse (there are number jumps if i move to fast)? and is it possible to get the position and the size of a gop?
@Jona Jumps in mouse data are maybe due to interrupts for audio? There is quite a bit of jerkiness in Pd Gui's to try to ensure proper audio processing when dsp=1
If you mean position of the gop on the parent....... yes.
Give the canvas send and receive addresses and send it the message [get_pos(
[unpack f f] the message it sends back for x,y
The size of the gop can be set...... but interrogation..... unsure for the moment.
thanks david, now it works nice without externals, still you need the experimental mouse plugin in your extras folder: experimental_mouse_plugin_7h.zip
jumps in mouse data exist also with dsp 0. its when i get mousecoordinates, but also if i move numbers in a number box or a slider with the mouse, it depends on the speed of the mouse.
in contrast if i move data structures with the mouse i get every value. its not a serious problem, but i was wondering.
i removed list-rev for finding pointers in a list in the struct sequencer, now the drawing is much faster. theres a 16, 32 and 64 step version. in the 64 step version you can almost paint something and play the "painting". @whale-av in the 64 step version you see the jumps of the mouse visualised in the pattern, in the other versions the mouse tracking is accurate enough: structsequencer_mouse_plugin.zip
i build a function that generates melodies. choose nth, and manipulate nth1 and nth2. it works without the mouse plugin but then it gives error messages. perhaps i will also build it into the sequencer version without the mouse plugin. for testing i connected the sequencer to the nice polywavesynth from http://www.pkstonemusic.com (which requires cyclone, and mr peach for osc): structsequencer_mouse_plugin64step_nth_polysynth.zip
The tot's third outlet optionally captures a stream of Pd gui messages dealing with user control over a destination canvas.
i.e. motion, mouseup/down, keys, etc... of specific chosen windows (title passed by message or argument).
How could one translate the window ID in jona's plugin to the window title?
@kyro I don't think the window title can be returned.
Pd obviously knows the canvas by its os filename as you can send a message directly to it through [;pd-mypatch.pd(
But the new [pdcontrol] object doesn't offer the patch name, only the paths to it.
Tcl refers to the window index returned by the os when the window is opened..... $focussed_window in this case.
The hcs library has tools for retrieving the index as does the iem_guts library.
You can set a supplementary name for your patches with [namecanvas] so that other canvases can send messages to them without knowing the window title.
In experimental-mouse-plugin the $focussed_window is sent before the mouse info.
You can get the window ID for the window the mouse is actually over..... focussed or not....... with %W and then filter for it like this.......
You will need the hcs library for [window_name]
You could test for $focussed_window(join ".c") == %W within the plugin and only send the mouse info when that is true..... but it would still send to all [mouse_receive] objects.
Interestingly, if you attach a print within only_me.pd and look at the incoming messages, you will see that %W does return the literal name for the console (pdwindow) and other tcl (owned by wish) windows..... but not patches (owned by Pd).
Thanks a lot, @whale-av, I think I know what to try! If I want to listen to [pd mysubpatch], I just have to get its id with [window_name pd-mysubpatch] and filter out the messages from other windows.
$focussed_window(join ".c") == %W
Where can I learn more about this wizardry? I wasn't able to get key info from the plugin, I don't understand how to use commands from the tcl doc...
Nevermind, <KeyPress> steals keys for itself and turns pd unusable.
Thanks for that %W trick, I now have the mouse features I was looking for.
@kyro P.S. "$focussed_window(join ".c") == %W" was my pseudo code for add .c to the focussed window name.
There are some people on the forum that can play nicely with tcl.
I have just learnt by experimentation and trying to understand what is already in the pd/tcl folder..... a sort of guesswork with clues really.