Just curious if Cycling74 has considered making additional MSP cables? It might be nice for the sake of workflow and quickly mocking up patches to have a single cable that splits in a "Y" at both ends. Same for a "Y" at one end only.

feature-request-additional-cables

you can achieve the same result by clicking on an inlet (or outlet) while holding down the shift key and dragging to more than one outlet (or inlet) of the other object(s), (then select the cables and do a command -y to bundle them up)

Kind of--but that only works connecting one outlet/inlet to multiple inlets/outlets. You can't connect two outlets to two inlets in parallel, without repeating the process.

There are extra steps involved when using the method you mention, like reselecting patchcords after connecting them to bunde them. If one is working quickly it is easy to anchor cables to unwanted spots on the screen using the shift key.

So I still think the dedicated cables I proposed might help improve workflow for many....

Kind of--but that only works connecting one outlet/inlet to multiple inlets/outlets. You can't connect two outlets to two inlets in parallel, without repeating the process. 

There are extra steps involved when using the method you mention, like reselecting  patchcords after connecting them to bunde them. If one is working quickly it is easy to anchor cables to unwanted spots on the screen using the shift key. 

So I still think the dedicated cables I proposed might help improve workflow for many....


Also, when you begin to move connected objects in a patch, routed cables are not as convenient as a single cable...and the auto-route command may keep the cables separate to avoid objects.

have you got this patching tool-- max toolbox?

have you got this patching tool-- max toolbox?
https://github.com/natcl/maxtoolbox/


Yes, thanks. Toolbox is another workaround that still does not accomplish the simple goals these cables would.

The whole motivation for this request is to simplify things--where the are two wires, we would deal only with one. Easy idea .

The idea could be of course be extended further, to allow true bundling of various numbers of cables-but the stereo and mono configurations are so common that simply adding the two cables I proposed could improve many workflows.

Yes, thanks. Toolbox is another workaround that still does not accomplish the simple goals these cables would. 

The whole motivation for this request is to simplify things--where the are two wires, we would deal only with one. Easy idea . 

 The idea could be of course be extended further, to allow true bundling of  various numbers of cables-but the stereo and mono configurations are so common that simply adding the two cables I proposed could improve many workflows.

...for the cost of the introduction of different types of cables.

for bundling, you can do that using [prepend] and [route]. while for stereo it seems overkill, i do that for 8 and 10 channel audio sometimes.

i also do it for video connections with additional custom meta info such as dimensions (per-frame or only one time messages)

i am totally in love with the interface of flowstone and its freely bezier-curvable cables.

it will never replace max/msp for me because i refuse to learn assembler languages in order to play with tapping buffers and filters - but it is astonishing to see that you can make an app which opens the sound driver and loads 500 externals in less than one second (where programs like max/msp, supercollider, xcode or dreamweaver need almost 30 seconds to do the same)

flowbezier.jpg

look at my multicore~ and route~ patches. In the St.ools abhaxions, you'll also find some multicore send and receive objects...

They work as multicores, but are not supported officially (might break in the future) and another drawback is you have to restart audio to make the connections. I vote for official multicores, they are indispensable for me...

look at my multicore~ and route~ patches.  In the St.ools abhaxions, you'll also find some multicore send and receive objects...

They work as multicores, but are not supported officially (might break in the future) and another drawback is you have to restart audio to make the connections. I vote for official multicores, they are indispensable for me... 

Hi Roman -- I am not familiar with flowstone-- thank you for mentioning it. I will take a look out of curiosity.

Thanks as well for mentioning your objects, I will take a look when I have some time

Feature request: additional cables