If you wanted to make a midi synth slide between subsequent notes rather than move in discrete steps could you use line to move between the notes as they are input? How would the decimal values be interpreted in between the incoming midi note values?

I am trying to get a smooth sounding curve between the notes.

In other words, without using a pitch bend wheel, just a keyboard, I want make something that will take the first note pressed (say midi note 69) and then slide to whatever the next one pressed is. I suppose I could then modify the sliding speed etc...

Polyphony is not the problem I understand how to do that, the problem is getting subsequent notes to slide between each other rather move by discrete steps.

Hope this question makes sense. Any ideas how to make a start on this would be much appreciated. In the meantime I try the line idea.
Jorge

Are you talking about building a synth in pd, or sending midi messages from pd to control an external synth? I'm not 100% sure, but assuming you're talking about the former:

You might find that polyphony is hard to reconcile with the glissando idea, actually - many 'gliss'-type synths only allow this in monophonic mode.... The reason being, it's hard to specify which of the old notes you want to slide to the new one that has just been pressed. Nonetheless, it is possible; you should just be aware that that aspect might be tricky and/or involve some compromises.

Anyway, I think the [line~] thing would work, but here's how I would go about achieving a simple, monophonic version of this kind of thing would be with something like the following:

[notein]
|
[sig~]
|
[lop~ 2]
|
[mtof~]
|
(your synth here)

That's a pretty unconventional use of [lop~], the low-pass filter, so I'll take a moment to explain it. Basically, the signal from [sig~] jumps immediately to whatever midi note you feed into it. As far as [lop~] is concerned, this jump (discontinuity) is a mixture of many different frequencies. Since its argument is 2, it will only let through the frequencies below around 2hz... This has the effect that it slides to the new note slowly, in about half a second, or a little more. You can raise the amount of time a slide takes by lowering the argument to [lop~] to 0.5 or so if you like.

Hope that helps! Post again if you have any other questions.

wow, Stutterer, thank you. I would have never thought you could use [lop~] in this way...sort of like a data filter.

I will try to clarify and attach what I came up with...

So, yes, the sound is being synthesized in pd, not externally.

I like the old sound of the portamentos on several analog synths, but that is not really what I am trying to do. I would like to be able to have a variable glissando rate, that takes the current midi note state and slides to the new state when a key is pushed. Certainly starting monophonically would be better (after all, if you are playing chords, how would the program know which notes should be slid in which direction towards the next event - probably I wouldn't care, and just do it in terms of chronology...events triggered after others would result in the immediately preceding event sliding to the later. Of course this would mess with the polyphony if one didn't press all they keys at exactly the same time (which happens every time) there would need to be a filter to quantize the window during which one event is considered one event and not several)

but this is a digression and probably sounds nonsensical anyway...
basically, thinking monophonically, I would like to set up something that would behave like a simple envelope generator, but instead affect the frequency (midi note number) of the existing state, and move it, sliding, into the new state.

I am going to try this low pass filter idea later on, I will attach my hackary below so you can see how I resolved part of it.

I managed to get it to slide, but the problem now is that I think the program interprets what would be the note off part of the message as a new destination and slides to that. Worse is that the note off message is probably not being received..ln any case the events once triggered last forever, or at least until it seems that some maximum is reached and this sort of voice stealing occurs, changing the texture. It would be great to be able to end the notes too though!

That, it seems is my main problem with this setup.

I have a few disclaimers -
I can't attach the whole patch because it is my performance patch and it is insane. It is not very neat, for example, and also includes other pieces that still being developed, so it would just distract. In fact, I think it only makes sense to me.
Also the synth isn't even done, but it is based on polysynth~ of which several versions exist on this forum, so you can plug the data coming out of these little modules into that to see how it works.

Also, these patches contain a few things (on and off switches) that relate to other things in the patch that obviously are not included. I thought about cutting them out, but then, if part of the problem is in this interaction it is best to leave it.

Ok, enough disclaimers, hopefully you will be able to see what I am trying to do from the control level attached. I wonder if [stripnote] and some kind of rerouting could be the solution...

http://www.pdpatchrepo.info/hurleur/alphabet_control_subpatch_input.pd

here is the second part of the patch.not sure how to attach more than one file here on the forum

http://www.pdpatchrepo.info/hurleur/alphabet_control_subpatch2.pd

It's kind of silly, but to attach more than one file to a single post, you first have to make a post and attach one file. Then, edit the post, and you will be able to add more attachments. Not sure why it's done that way. Maybe to prevent spammers attaching a bunch of shitty files.