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

@Carambolooo Float before operator like in the rightmost message [2 /(

@Carambolooo Objects like [- 2] and [/ 4] are ultimately just lists and things get easier if we treat them as such and just stuck them in messages. Once we do this we can just route things as needed and this also means you are not limited to bangs, you can send the appropriate list. I also added the ability to switch the operators, if you send [2 /( and the current value is 6 you get 0.333, but if you send [2 /( you will get 3.
accumulate.pd

@fishcrystals said:

sounds like if anything I should introduce more aliasing

If you want the CZ sound you want the aliasing and the 17khz filter, use fx to smear and hide the aliasing like we did in the old days. With my aliasing free 192khz interface I find the CZ oscillator seriously lacking and sterile. People go out of their way to avoid aliasing and noise but aliasing and noise are a big part of the sound of much of our classic gear and their effect on the sound is far more complex than just noise and aliasing especially when you add fx into the mix.

@seb-harmonik.ar said:

edit: actually cz synths had aliasing afaik..

The 101/1000 called it good with a second order lowpass tuned to 17khz. The common VCF mod for the 101/1000 was just making that filter variable instead of fixed so you could get all the aliasing you wanted.

@EEight Regarding room calibration, it may not matter, depends on the situation. People absorb sound and affect the room, if the room is going to be full of people and it is a small room all your work could do more damage than good, but if it is a big room and there will never be more than a few people in it there could be a real advantage.

Regarding phase, phase cancellation could be a benefit if people are going to be walking through the room, increasing phase cancellation will make the sound more dynamic as they move through it. But lots of variables, depending on room size, what is being played, volume and a good number of other variables you may get more cancellation with the phase inversion on one channel. Sort of thing which takes some experimentation to figure out what works best for what you are doing.

@Aliam.Sigsaly [switch~] is vanilla but just add the appropriate [declare] and your patches will work with most all flavors of pd. Your [> 0] -> [+ 1] -> [gate 2] and [sel 0 1] can be done more efficiently with just a [moses] and a couple [t b f]s. I also used [value] for the numbers to be interpolated between which makes things neater and allows you to use [send] to set the value. The issue with sliders are that they quantize to pixels, this is not much of an issue if your numbers are close together like in your example but if your number are 1, 2, 984 you start noticing issues, but often still good enough for the job.

Interpolation.pd
Edit: Also, if you rework the equation so $f5 is $f1 you get a bit more efficiency since it saves a type conversion and also makes things a little neater, fewer objects. Forgot to do that in my rework.

@evankelo [iemguts/receivecanvas] might be a better option for dealing with the mouse if you are not using gem for other things as well, [iemguts/receivecanvas] only puts out mouse events when they change instead of constantly. We can make gemmouse act this way with [change] and we can further slow things down with a [metro] if need be. Here it is implemented with [iemguts/receivecanvas] since I do not have gem installed.

@4poksy did you set the receive symbol of the bang?

@atux Most likely who ever packaged pd for your distro did not include Jack, My bet would be that your distro has adopted PipeWire and there are still some bugs in the packaging process regarding it, maintainer made a faulty assumption or the distro does not understand Jack and how PipeWire works with it. If you have not tried 0.54 recently it could be worth giving it another try, they may have fixed it and a good amount of fun new stuff has been added since 0.52 like multichannel audio objects, many new methods for [file]. If they have not fixed it I think this would be worthy of a bug report. But worst comes to worst, pd is very easy to build from source.

To make it work with 52.1 you can just set the path, remove [file patchpath] and connect the [loadbang] directly to the [symbol $1/images/*( message and replace the $1 with the path. Or you can use [openpanel] to select your path, replace [loadbang] with a [bng] and [file patchpath] with [openpanel].

@atux 0.52 does not have [file patchpath], introduced with 0.54,

@porres EEight, maybe whale-av (I believe he is a mod) but I don't think it is worth the time, no one will read past the first few posts of this thread and he probably will not stick around here anyways since he is giving up on Pure Data, ignoring him will solve the issue without mod intervention.