Hello everyone,

I am very new to PD but I am trying to build a microtonal polyphonic synthesizer where one can modulate the pitch of each of the 12 semitones in the chromatic scale individually, similar to what was possible on the old Korg PS-3100/3300 (why don't they do that anymore??). Here is the patch so far (using float in the example):

Polyphonic Microtonal Synth.pd

My problem is in getting each midi note seperated to each oscillator for pitch modulation. I used (select) and then the midi note numbers for C, C#, D, etc. to seperate the notes to each oscillator but then (select) sends bang, not the note number pressed, and I had it connected to a (mtof) object but of course it does not work. Using (float) also does not work well because it stores the previous pressed value (see example patch above).

How can I select/filter a given note out of the chromatic scale and then have it passed on onto the oscillator for individual pitch modulation? Pardon my ignorance but I already tried several things without success

Thank you!

My pleasure, Helder. If something still doesn't work, feel free to post new questions here. As for sharing your final patch, that's very nice of you; I would only suggest that you do so in the appropriate subforum (such as patch~) and not here at technical issues, just to keep everything organized.

Take care,
Gilberto

Ok, I've made the first tries. The problem I found with your patch is that it does not organize numbers ascending. For example if the midi note number coming in is say 38 (a D), then the notes coming out are organized: 36 (C)...ascending...but until you get to F, which becomes 29, then again ascending. See image here

I will have to spend a little time with it to see if I can fix this but any pointers from anyone would be appreciated.

Helder, I can't see the picture you are trying to upload. Could you please edit your message and upload it again? Sorry but I still do not understand your problem exactly.

@gsagostinho Sorry, I was not able to upload the JPEG for some reason...But if you click on the link it will work I think.

What I also tried to do was to try to store a variable (I called it $1, but not sure dollar-sign variables would work here) with the incoming midi note number. Then I would use (select) to select the different 12 notes in the octave, and then if they match a certain note the $1 variable would be recalled and transformed in frequency through (mtof) that then could be tweaked?? See this patch: Patch.pd. Could this approach work? I just don't know how to store and recall variables later.

Hi,

Your patch above has some problems. First of all, what you are sending is only bangs, not floats, since you are using [select]. Second thing, I don't think it's a good idea to call your send '$1'; you can call it anything you want, but the dollar sign variables are a completely different thing altogether: they can be used to replace arguments when calling an abstraction or a subpatch. Example: in your patch above, if you'd save it as Patch.pd, and then in another patch you would create [Patch argument], every single $1 will be replaced by "argument".

Now have a look at this, here, it might be an easier way to solve your problem: patch2.pd

But note that while this synth will be polyphonic, it won't be able to play octaves, since you have only a single oscillator for each pitch class.

Maybe it would be a better to have a complete different approach altogether: give me some mins and I will prepare another patch for you showing how I would try to tackle this problem, ok?

Take care,
Gilberto

Oh man, that is great help. I am really struggling with this. Thank you for giving me a hand here. I think this is the most difficult part, after this it should be fairly easy to add the other components of the synth. Btw, I knew the problems with dollarsign variables and (select) using bangs but I was not finding an alternative...float, etc. also did not work because it stored the previous value to the one I wanted to trigger the oscillator voice (it would play an A when I trigger a C if I played an A before C for example).

No problems at all.

Have a look on this and see if it behaves as you want. I can explain the algorithm to you if something is not clear. I am using an abstraction named [abstraction], which can take two arguments (one is the midi note and the other is the name of the note, used to bend the pitch. This way, each single key will have its own oscillator, and so you will have true polyphony.

Please save this file as abstraction.pd, since normally downloading files from this forum messes their names up: abstraction.pd

And here is the main patch: patch3.pd

I hope this helps, and let me know if anything here is confusing, ok?

Take care,
Gilberto

NOTE: I don't have a MIDI keyboard connected to my notebook right now, so you will need to test it and let me know if it is working for you or not, ok?

Man, you are really really good. What you did in a few minutes would take me probably several months to achieve I will study your patch and try to add to it. It is responding to midi notes from the keyboard but the envelope generator has the gate always opened - no good. I will try to work on building a decent ADSR envelope. In your patch 2 btw the envelope was closing at noteoff but not on this one - should it? From what I understand also octaves have to be added the same way you added 2 (collumns of abstractions). The microtonal adjustments work beautifully. Because in this patch3 the gate is always open it creates a drone where you can be tweak each note individually. Beautiful work man, congratulations. You must have years of this, yes?

Hi Helder,

I am glad I can help. About your questions, the [spigot] objects should not be always opened and they shouldn't have any drone effect, I will check what is going on with it. As for the octaves, you are right, just add columns and use the correct midi numbers and note names, just like I did. You can edit the abstraction and add all sorts of fancy things, like ADSR envelopes and things like that. And I am patching for a couple of years only, but once you get the hang of it you will see how to think as Pd does

Give me a minute to figure out the problem with the drone effect, I already suspect I know what is going on.

Try this modified abstraction.pd (the main patch remains the same). It should do the trick now.

What was happening is that the note velocity was arriving before the [spigot] was opened, so that was why it was being ignored I believe. Could you please test it one more time?

@gsagostinho working beautifully Thanks again. This is definitely not my patch anymore - it is a joint effort. thank you Gilberto. I will then try to add classic synth-stuff to it like different waveforms, filters, envelopes, etc. and some midi control.

Take care and best wishes,
Helder

Great to hear it works now, Helder. Good luck and take care,
Gilberto

hey gsagostinho , what version of pd are you using? i would like to have the nice bended connections too =)

@tomchaossen Hi Tom,

It's a distribution called Pd-l2Ork (see: http://l2ork.music.vt.edu/main/?page_id=56 ), which is based on pd-extended. It contains a LOT of improvements over pd-extended, particularly related to the GUI. Right now it is only available for Linux, but it's likely it will be available for Windows and OS X in the future (and well, there you have one more reason to migrate to Linux if you are still not using it ).

Take care,
Gilberto

thanks for the info, and im using linux =) already building pd-lork ...hope it works without libsndobj ...

@tomchaossen

Tom, if you are running a Debian based distribution, you can simply download the .deb package from that link I sent you. But if you want to compile it, you will get some of the newer features. Also, if you have pd-extended installed in the same computer, you will have to force the installation of that .deb package. Let me know about it so I can give you the details.

Take care,
Gilberto

im using arch-linux and i feared it would break the build process without the libsndobj-cvs ´, but in this second the build completed.. but thanks for the quick respond and help offer

@tomchaossen No problems. And just one more thing to keep in mind: Pd-l2Ork has broken binary compatibility with pd-extended and vanilla. This means that some externals will not work properly on it (but there is a way of compiling them for pd-l2ork, although I never tried it myself). That is by far the worse limitation of it. But if you work mainly with the externals that comes in pd-extended (all of which are included - and some improved! - in pd-l2ork) then there is no loss at all.

EDIT: I myself use it 99% of the time, it's only when I need to use the HOA library that I turn back to pd-extended or vanilla. But as soon as I manage to compile it for pd-l2ork, then I guess there is no turning back for me

one or two externals i would like to compile like the great tabletool, but i think i will get them working somehow, btw, wow...the gui looks nice