Hallo, David F. Place hat gesagt: // David F. Place wrote:
The patch implements a tone generator for Pythagorean tuning with syntonic comma offsets. I hope it will help my renaissance flute consort to learn to play in just intonation in the style of Zarlino.
So, it has to be usable by non-electronic music people. It does what I want. I would appreciate if anyone could review it for style and understanding. I suspect that I have done some unnecessary things do to my imperfect understandingOne thing in particular that it does in a way I don't like is setting the note name. I would prefer to pass the note name as an argument to the noteSelector abstraction instead of having that bit of [set( and [send] circuitry off to the side of the noteSelector, but I couldn't figure out how.
Now I could look at your patch, very nice work and a great idea to start with. The solution to your "set note name"-question isn't too hard:
Besides numbers you can also pass symbols as argument, so you could call noteSelector like this: [noteSelector 32 27 F-Natural $0]. Then "$3" inside the abstraction would be replaced by "F-Natural". However of course you cannot use a [f F-Natural] as that is illegal, you need to use [symbol F-Natural] instead. Connect a message [set $1( afterwards and send it to "$0-note" or rather [s $4-note] if you pass $0 as fourth argument.
Btw: A generic container for both float- and symbol-arguments is [list append] like this: [list append $3] here is equivalent to [symbol $3], but if $3 would hold a number, [list append $3] would be equivalent to [f $3], because [list] automatically converts single-element lists in a smart way to float- or symbol-messages.
I have one criticism to make as well. Long term pd-list readers will already guess what's coming now: Sooner or later you may run into problems with the execution order in your patch because you didn't use a single [trigger] object in almost all of your abstractions. (Only two triggers are used, which you copied from the examples.)
Triggers are important to use wherever you have "fanning" connections, that is, more than one patch-cord running out of a single object. The order, in which the messages are transported along each of these patchcords, is *undefined* in Pd! You may consider it as randomly (even when in reality it isn't).
You have a lot of these, for example every bng-object in your patch is source for several patch cords. This may work now because you're lucky and the connections actually fire in the correct order by coincidence, but as soon as you edit the patch a bit more and re-connect stuff, it *will* break. Promised.
Attached patch illustrates one of the ways your patches will break.
So you really should make yourself familiar with the way, execution order in Pd works and with the trigger-object and replace all fanning connections with correct triggers.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__