@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.