jayrope

Is there a way to establish drag and drop connecting of inputs and outputs of bpatchers?

Like i drag bpatcher A over bpatcher B, get a dialogue window to connect either output (signal or not) of A to B or vice versa?

drag-and-drop-connect-bpatchers

in case you are in root, and in case the bpatchers have a known number of inlets and outlets, and in case they all have object names, you could do that by oldstyle scripting and finding the "overlap" states by using a combination of cursortracking and remembering which object is placed where.

eventually the size of the batchers must also be known.

also wenn dir wirklich, wirklich langweilig ist, dann machs so. ich würde es nicht machen.

in case you are in root, and in case the bpatchers have a known number of inlets and outlets, and in case they all have object names, you could do that by oldstyle scripting and finding the "overlap" states by using a combination of cursortracking and remembering which object is placed where.
eventually the size of the batchers must also be known.

Top Idee, 110 :) Is there an easier way? Cause there should be. It is an unbeatable feature, when building apps for others. Modular, easy to use, and all. Not implemented? Come on, feature request, Cyclings!

Puh I don't want to search for this rigth now but there are similar things. Somebody coded some kind of virtual patchbay where you can make connections via graphical location and draging boxes around..

Here's a javascript I wrote a while back to help Brandon in 

. It reorders [bpatcher] files based on their vertical position within a patch. I haven't looked at it in ages but a quick test shows it still does the job. If it's not quite what you need then let me know as it shouldn't be too difficult to modify (for example if you want switching done by horizontal position, or multiple [inlet][outlet] connections made).

Here's a javascript I wrote a while back to help Brandon in this thread. It reorders [bpatcher] files based on their vertical position within a patch. I haven't looked at it in ages but a quick test shows it still does the job. If it's not quite what you need then let me know as it shouldn't be too difficult to modify (for example if you want switching done by horizontal position, or multiple [inlet][outlet] connections made).


connecting "virtually" is something totally different than actually connecting and, in the end, you will still need to make the real connections somewhere. :)

also, this would mean that you need to have the "virtual" stuff in background, in best case thats an lcd object ... which wont be big enough for a big monitor and makes moving stuff in front of it slow plus it adds the risk of drawing bugs.

also, this would mean that you need to have the "virtual" stuff in background, in best case  thats an lcd object ... which wont be big enough for a big monitor and makes moving stuff in front of it slow plus it adds the risk of drawing bugs.


"Modular, easy to use, and all. Not implemented? Come on, feature request, Cyclings!"

i´ve made quite some tests with things like that and never found a useful solution.

with FMM and 110.modular for example i am script-creating my modules already, but the are created all with the same name. if i now also had to store the unique names and the size info somewhere in the root patcher, and recall it from there, i would start adding code to the root level of the patcher, which somehow is against the idea of patching with bpatcher "modules" (_instead ofpatching max externals).

i wonder at which point you are, have you tried something already?

such a design would, apart from the question how difficult it is to make, only make sense when you use it conseqently through your software. what should happen when you drag a third module to the two which are already connected? what should happen, when there is a module at 0 0, a second one at 0 1000, and you now move the third bpatcher with the mouse from position 300 500 to 0 500? should it be connected to both? or to none of them?

this autoconnect stuff brings up dozens of new questions.

with FMM and 110.modular for example i am script-creating my modules already, but the are created all with the same name. if i now also had to store the unique names and the size info somewhere in the root patcher, and recall it from there, i would start adding code to the root level of the patcher, which somehow is against the idea of patching with bpatcher "modules" (_instead ofpatching  max externals).

this autoconnect stuff brings up dozens of new questions.


110, good questions. We should have a chat about those things. I am as far as creating (almost) all modules and associated sends and receives using individual names, and i only need one in and one out per object right now. So, chat, how?

drag and drop-connect bpatchers?