get message when inlet/outlet is clicked in a bpatcher?
is it possible to get outlet message or a bang when outlet is clicked?
hover, mousestate
dont know if that works with bpatcher
Yes already tried mousestate
works in bpatcher
but only when you click on the object
and only when locked
more specifically - I need hover or click, bang or message, on inlet / outlet (little connection circle) when patch is unlocked
I think preferably 'hover' since 'click' only/mostly happens with outlet and connection to inlet is 'release'
so hover seems more universal
however - it might be possible to shrink this pwindow so tiny that it fits inside the little yellow circle and doesn't interfere with making the connection - while at the same time send the message when clicked
//hover would be better but OK - - can work around it - senders actually don't matter, they never change and can be hard-coded - - its the receivers that often change - so connections should be made from receiver to sender when using 'click' and not hover//
but noooo... how can I start from where I'm going if I don't know where I came from?
getting mouse position might work from inside, from outside the outlet position can vary, especially for regular objectboxes, depending on content and fontsize...
ROMAN THILENIUS - hover bang over outlets was a great idea 'in the moment'!
...got scrapped for better 'worse' idea!
maybe you can help get loadbang inside bpatcher?
can't use [s init] -> [r-init] /// doesn't seem to work even with long delay
this is a very strange bpatcher.
I need this [onebang] inside a bpatcher so it doesn't interfere when I load other copies of the same bpatcher (maybe writing this sentence help me realize it might not make sense)
but that means I would have to ID the actual onebang so it doesn't bang again when I load a copy
I read some old forums with same situation - I should read some more
in the console:
...as you can see - initially patch does NOT bang [print receive] when loaded using the [s init] method from master patch
then patch 2 (which is a copy using 'instance' method from TFL) is re-banging patch 1 [print send], then patch 2 [print send] then finally the patch 1 [print recieve]
I can't figure out why I have load a second patch to get the first patch recieve the init
and as mentioned - putting long delay on the [s init], to wait for bpatcher to be created and populated with #0 and #1, still nothing
given more time, I can figure it out...
loadbang to thispatcher?
nope
//
I don't think there is any way to do this without making a separate [script sandbox ***replace ***]- and hardcode every object - yuck
However, again now that I read this last statement maybe "replace" is the problem. But only found
create bpatcher, then to fill it use replace - there must create bpatcher and create whatever is inside?
// I guess it doesn't need to be a bpatcher- the patch in question is already in file path, can easily open as top level patcher and feed it info- still using same scripting and args
//
probably if had any sense of what is going on, I could do it all with js
your question is far too long for my small brain.
thispatcher scripting is usually threadsafe, as for dynamic naming of forward/receive from a loadbang which requires the s/r connection directly afterwards... i can not tell by heart. scripting by js? even with deferlow? i can only guess. my hindi is better than my js.
for my part, when i feel the need to #0 autoname both s and r at init... i overthrow the idea to use s/r because i notice they are in the same patcher.
maybe it is time for "max extensions" (like "live extensions") which give you access to these things. for bpatcher worlds the idea is understandable.
are you trying to track connections when changed manually?
remember "happy inlets"? (images)
https://cycling74.com/forums/possible-to-save-patch-cord-connections-when-using-pattrstorage-andor-scripting#reply-672164554db838001323fb07
Close- with the happy inlets.
I’m doing something similar to OP in that post.
Except ALL my floating windows are Separate parches.
And I’m making a crazy new storage and architecture. .
Each patch, when opened , creates a second patch that contains the chord connection.
Then the audio from the first patch is sent to inlet in second patch. Which has an mc.receive ~ connection. All the inlets and outlets are creat d in a master patch that is invisible when locked.
The inlets/outlets are scripted to fit directly under the small patch , and follow it when I drag it around the screen.
This way I can make normal chord connection between Separate patched instead of send~ receive~ // one outlet can be connected to many different patches. Like the master Beatmaker to many different synth.
everything works flawlessly with creating patches- hover,drag,follow etc
Just need to ID the audio to and from each inlet/outlet in coupled patches. And I want each instance to receive its label - [set chord_conbect_module_1] for example- then lock it so it never changes and gets destroyed when patch is closed.
It might actually be as simple using an auto closing gate . Something that is system unique between bpatchers like dials and sliders. Maybe toggle.
I get back when find solution
//
Ah. pcontrol. Maybe.
Like this
(the question in this post is my answer:)!
very powerful
and simple
max
when understand better
can your current method survive its state when window #13 is closed?
Haha. Arnold Schoenberg lived his whole life petrified of #13. He did all kinds of calculations to find out the year or date when he would die. Ended up forgetting to add his age together . 76 = 7+6 =13 . He died at age 76 Friday July 13.
I tend away from superstition and towards prime number and fibonacci numbers- the first intersection is 13 so for me that is a golden number
Also Zappa "13" is a great song to dance to (jokingly) and count along to.
//
So far still testing haven't reached 13 windows open. The idea is to have hundred of windows available (performing a wide variety of tasks) but really never more 10 or so open at a time. No need right -- sound will be too cluttered -- who knows - maybe I will try 13 instruments playing in tandem to create a big fat monophonic timbre - deviate