@cfry Right, as I said in the post where I first posted the patch, I assumed sane connections, that a jack would have to be unplugged before something else could be plugged into it. The logic will work with y-cables and stackable cables but only the logic as things stand and that is only because I skipped error checking because of the assumption I made about sanity. I left some work for you to do. [throw~] and [catch~] don't complain as much as [s~] and [r~] do and are generally less annoying to work with. And there is maybe some external with none of the multiple defined issues, no clue.

This method and [marix~] can be mixed, just replace the symbol with what [matrix~] wants and rewire the s~ and r~ outets of the [sel]/[route] as needed.

@cfry said:

Sorry but I can not figure out where to put this :/ The pd.pd abstraction looks slightly different. It looks like you have merged what was previously two paths with parallel [route] objects.

I just showed one of those parallel paths since they are identical other than where the [route]s go and the [set( messages, one side handles send and send~ and the other side handles receive and receive~ and send it to the appropriate [set( message so the correct elements of the list are edited. Here it is merged as a single path with the [obj( message tweaked to work with the new data flow.
pb1.pd

Edit: lots of mistakes fixed.

@cfry The s and r can be reversed if you want. The [obj 10 $5 dynpb $1 $2 $3 $4( message is just creating an instance of dynpb with $1-4 as its arguments, the abstraction has two object boxes [$1 $2] and $3 $4] which on creation get expanded to that arguments, I just did it in the order I created the objects when I patched up the abstraction so all the dollar arguments would be the same between the message and the abstraction, you can change these as you feel fit as long as you make sure r <symbol> end up in the first object of the abstraction and s <symbol> end up in the second.

No problem with s~ and r~, just add them to the routes and pass the list from the [text] foreward so we can set the first and third items of the [list store] as well, something like this but without the error in the message like I did, setting the wrong index.

And you can add in throw~ and catch~ if they suit a task better.

@junhans Once is a common little patch which often comes in handy.

@DimitriosG I would expect the standalone version of PlugData to have something like vanilla pd's -noloadbang startup flag, I'd even expect it too use the same flag as pd just for sanity's sake but who knows. But renaming any [loadbang]s from a text editor generally does the trick,

@whale-av said:

Deleting any [loadbang] objects might well help as a first step

You mean renaming, deleting will generally have disastrous results since it will throw off object counts in the connect messages.

@cfry This should at least mostly work, not completely clear on how the patch panel of the MS-20 controller works or your exact intentions so I made some assumptions. It assumes sane connections and will fail if you try to connect two outs or two ins because of how the message is constructed and it does not check for duplicates which is a good thing if the controller allows the use of y-cables. It also assumes disconnects happen before a connect, which should be safe since you can not plug something into a jack without first unplugging what is there unless it works with stackable cables and in which case this is a good thing.

pb.pd
dynpb.pd
I left off the [load bang] so you can step through everything and watch it happen and see what is going on and send it incorrect messages and see what happens, etc. Open [text define $0pb], click {clear( to load the defaults then click step 4 times and watch how the [text] is updated. Now the float atoms at the top are connected and changing the values in the top two changes the values of the bottom two. Start work through the six list boxes top to bottom and see what happens in the text and too the float atoms. You should be able to sort it out fairly quickly with the help of some {print]s and/or list boxes, the logic is fairly direct.

I have the [text] formatted as jack number being line number, its connection status as you did in your [list store] version but -1 instead of 0, followed by default connection (possibly not needed depending on how the MS20 works, does it send the default prepatched connection after a disconnect?), s or r to say if it is an input or an output and then a send or receive symbol without the $0. The $0 being added to the symbols externally means we can stick this all in an abstraction and just send the parents $0 to the right inlet of the three [list $0] and still have everything work as it should. The [iemguts/sendcanvas] should probably be replaced with a send to a subpatch and a subpatch to send too, I did it that way so you can see what happens as it happens.

@Carambolooo I am pretty sure I saw a pr for adding this to vanilla on the github page. If you are going to build pd you might want to check, the code to have this as native pd might be there for you to use then you don't need to open the All_about_else patch to get it to load, might even be in the current dev branch if it got accepted. Github is not working well for me right now so I can't check.

@cfry The catch with your [list store] solution is jack 0 would always have jack inserted in it, but you can fix that by just making no connection be -1 instead of zero. I would use text since we can store more information this way, jack per line with s or r or the audio counterparts and the unique symbol. Now a simple abstraction can do it all for you.

So a jack is inserted we get the appropriate line from the text, other side is inserted and we get that line, pack the four symbols in the appropriate order and dynamically create the abstraction with [obj 10 10 abs $1 $2 $3 $4(, and it creates the appropriate send and receive or what ever. When disconnect happens just grab the symbol and send a bang to <that-symbol>-kill and it deletes the abstraction. This also makes the prepatched modular style of the ms-20 easy, just send the default connections to be made at startup. And we can simply check if it is a valid connection as well, not connecting two outputs or mixing data and audio, etc or treat such things as jack inserted but no connection.

The one catch is that you need to have logic to avoid duplicate connections since if 2 is connected to 4 that also means 4 is connected to 2 and using sends and receives this way means you can created duplicate connections and each duplicate doubles the data sent, if you have two of the same connections that means you get 4 copies of the data sent.

Edit: Previous edit about issues with the abstraction idea was an error in my thinking, abstraction will work fine for this.

@junhans You are setting the frequency of the [osc~] to 8.513 hertz, your ears probably are not good enough to hear that but if you crank up the volume high enough and have a subwoofer you should feel it. [mtof] does not work on a 0-1 scale, it works on standard midi scale of 0-127 so delete the [* 0.01} and if you audio is setup correctly you should hear something.

@Ice-Ice It seems I misremembered, arrays do require the data struct color format but all the other GUIs can use hex now. For the data structure format it is just RGB with the integers 0-8 so 000 is 0 red, 0 green, and 0 blue which is black, 888 is white. Fairly easy to convert hex in your head to the data struct numbers.

@Ice-Ice Arrays and all objects (possibly not data structures) can now take colors specified in hex, makes life a lot easier. Fairly certain for it to be read as a hex color it must be proceeded by a #, so #ffffff and so on.

@gentleclockdivider lack of a trigger on the output of uzi to determine if expr or the [t b f] get hit first could do it.

@nicnut said:

One reason is that I need to put in every possible combination of intervals and scale steps into the expr. Maybe this is crazy as there are probably a hundred possible ways 2 notes can interact.

Now you see where I am getting at about this being tedious in native pd, imagine if you patched all that up and wanted to make a change, you could end having to a great deal of repatching because of a simple oversight. But I finally realized how to go about executing a general purpose language in pd that can be allowed to grow and adapt to the need and not just turn into a massive beast so I will throw together a more proper pd Forth which works well with the pd way this weekend. It will be Forth syntax so takes some learning for most but it is a very simple language to learn, only trick is learning to think like a stack. But this could be done for other paradigms, simple stack based language is just the most efficient in pd and easily can be made to be self adapting/modifying on both the language and program level which offers a great deal of power so worth learning its quirks.

And on top of that I want some interval combinations to have several possible weighted outcomes.

This is what @seb-harmonik.ar was getting at with the markov chain, not a big deal and we can even use the previous notes to calculate the weights.

Maybe this is too much work, but If I could do it it might be cool to use.

It is doable but the first time going at it is daunting, but designing a language just for executing that rule set makes things much easier and even easier than using something like the python or lua externals because it is designed around the task. Catch is you need to put in the work to develop that language but once you get the basics down you realize most music systems can be realized without too much effort.

@atux Difference in speed will be tiny, easy enough to test but generally academic on modern computers. For this sort of thing I generally go with what results in the neatest and easiest to read patch and rarely if ever get bitten when it is something so simple. If this is going to be an abstraction which you will be having hundreds of instances of then it can be worth counting those cpu cycles otherwise you can just be aware of the various possible solutions and pick the one you like best for what ever reason.

Most of the time when you start hitting the wall and experience audio drop outs or the like you would be better off sticking your audio in another thread with [pd~] then trying to find ways to save a few cycles, you are just going to hit that wall again when you start changing things. Still good to look for way to improve efficiency but generally you will get larger gains looking at the overall methodology of the patch instead of the minutiae.

@nicnut It is no where near as difficult to understand as I made it seem, you said you considered doing this in C++ so I did the patch in the C style. Forth may have not been the best example language but it is very transparent in how it functions in pd, but lets explain it in C terms.

Across the bottom we have our function definitions, the name of the function is the receive symbol, I defined addition, equals, duplicate and print. Top left is the parser which is just a while loop and an if statement, while true read input, if input is a symbol it is a function so run the function, if it is a float store it and push it on the stack. The only major difference from the C way is that we don't call a function with its arguments (add 3 9) we just run 'add' by sending it a bang and it takes its arguments off the stack. So you define the functions required to mark out the rules of counterpoint then you can either run it by just running the functions, compound commands as I did in the example or writing out entire programs in a [text], you can even change the rules while it runs or have it change the rules and alter its own programming.

PureData is a full programming language, not just a fancy modular synth like thing, we can use it to implement programming languages or create new ones of most any paradigm, with dynamic patching it would not be terribly difficult to implement object oriented programming complete with C like grammar (I think?), you could even write a compiler which compiles your language into a native pd patch instead of just interpreting it. Pd is surprisingly good at doing this sort of stuff which is a great thing since it has a few areas where it is awkward to say the least, defining the rules of music systems being one of them and what should be a minor change can result in hours of the worst sorts of patching. So we make a language with just the handful of features we need designed around the data we need to work with and the result we need to achieve and now we can make radical changes to our rules in minutes instead of hours.

This weekend I can go into this all a bit more and provide some examples more directly suited to your needs if you want to pursue this.

@nicnut For doing this sort of stuff I generally create little purpose designed programming languages since the patch interface of pd can get tedious when you decide to change a rule or the like with all the patching and repatching. For example here is a very simplified Forth style stack based language with four commands which you can see at the bottom of screenshot, +, ==, dup (duplicate) and print, top right is the stack and top left we see the program in the message and the parser bellow. Really it is just a fancy programmable route with a memory. pd is surprisingly good for this sort of stuff as long as you stick the lower level language styles.

4th.pd
So if we click the message to send the program it is dripped by [list-drip] into the [route symbol], any floats go out the right outlet and are pushed onto the stack, any symbols go out the left outlet packed with a $0 to create the send symbol for the command in the format of $0-COMMAND, this symbol is sent to the stack's output [send] and the parser's [send] which is then banged to run the command. 1 and 2 get pushed to the stack, + being a symbol is packed and the symbol $0-+ is made and sent to the right inlet of the parser and stack output [send]s, we then send a bang to the parser send. This bang gets sent to [r $0-+] which sends the message [2( to $0pop, two items are popped off the stack, 2 then 1 which are added and 3 is then pushed, and so on. With this setup we can make any block of pd code into a command so a very simple and reasonably efficient language can be very complex and infinitely expandable. The one catch is you really need to remember to keep the language purpose specific or you end up like me and have a handful of very large, complicated and difficult to maintain languages which while being really useful I have forgotten half the features of and : the idea of going through them to figure out and document them causes me to whither.

Edit: Sort of sidetracked myself there and lost my direction. Short of it is if you use pd in a more functional way instead of the dataflow way it makes it quick and simple to rewrite your rules or create whole new sets of rules without having to create entire new patches/abstractions every time.

And I will mention one of the handy aspects of [list store] in this sort of setup, it provides an easy and elegant way to grab a single element without storing it or unpacking the entire list or manipulating messages which generally is not a problem when the list is just three elements but can get messy for larger lists.

@atux Sure, I was addressing the original issue. Here it is with [list store] which gives a cleaner patch than [pack] and the two extra [t b f]s required, possibly at a tiny cost of a couple cpu cycles.

@atux We can also use list objects for this which frees you from the dollar arguments and need of clearing the message with a [set( which means the length of the list is not fixed and can make it much easier to construct complex messages especially when [list store] gets added into the mix where we can us its methods to change single elements without recreating the entire message on each change.

@whale-av If it were me I would just use a list box and type it all in but I assumed OP has a reason for doing it this way, possibly not a good reason but we all chase our tails at times. I would go with [list append/prepend] over {add2( for your way, having to {set( the message to clear it every go around seems an unnecessary step which is why I made everything a list in mine instead of making everything an any. One downside to the calculator interface is you either have preset numbers to select from or need an enter button, will be at least two clicks and could be half a dozen which is not great if you are trying to keep in time with a beat. List box has this same issue, OP might be on the right track.

I like these vague threads, get lots of ideas instead of a quick answer ending the thread.