I'm working on this (monophonic) granular patch attached (Archive.zip) and I've been having one issue in particular that really bothers me: if I play two subsequent staccato notes, the second note plays the first grain as the pitch of the previous note, and everything else is fine. Imagine if I played C4, then rest, then C3, I can hear C4 for the first grain, and then the note continues at the correct pitch.

So, I fumbled around a bit with the grain.pd and I got something working with a bunch of triggers. However, now it's like all the grains play together at the onset of each note, and then everything goes back to being fine. The problem is that I not only have a sudden spike at the onset of each note, as if I had an attack-delay followed by a sustain at, say, 50%, but also for that first part I get some considerable clicking, which I presume is PD's way of telling me that I'm having it do too much stuff at the same time.

In the grain.pd patch, there's a connection I marked as "cursed": if you leave it, you have all the clicking and spiking, but the pitch is correct. If you remove it, the audio is fine except for the first grain which plays with the previous pitch.

Any hints?

@morpheu5 you should send your grain pitch value as a second element in a list,
like [next $1 $2(

@solipp That's what I was doing but I was still hitting the "previous pitch" issue, then I refactored it with the [s $0-grainSpeed] because I thought it was an issue with a "leftover" float somewhere so I thought if I sent the right value to all the grains at the same time I'd avoid the problem but no.

See here: Archive 2.zip

@morpheu5 i guess you get the wrong pitch because the grain is already playing when you press your key (i haven't tried the patch). You can send a trigger + pitch value to [clone] when you press the key with [next(. Right now you are sending the trigger to all grains simultaneously.

@morpheu5 ...of cause, this would not stop the last grain playing at the wrong pitch. So you need to stop them all, then send the pitch value and retrigger metro....

edit: hope that's not too confusing

@solipp No, that's one of the solutions I thought of, but I couldn't figure out how to do it…

@morpheu5 i almost forgot [this( message to clone! check the helpfile, [this( + pitch should do the trick

@morpheu5 ...you could also use a counter instead of [next(, then retrigger the previous grain when you press a key. maybe that's the best option. sorry for the confusion, it's late over here

@solipp No worries, it's late over here too so I can't quite wrap my head around your suggestions. I tried the counter solution too, decrementing by 1 on note off. If I wait long enough between notes, I get the desired result. If I play them too much back-to-back, I still get the last grain in the old pitch.

I feel like I'm fighting against bangs here -- and it turns out the second archive I attached is identical to the first one. Anyway, it'd be great if you or anybody else could have a play with the patch because at this point it's clear I'm too much of a noob to follow any explanation

@morpheu5 From the first look you still use fan-outs in various places. For example in grain.pd after the inlet and after [r $1-grainDuration], also in granular.pd after the metro and after loadbang. So first step i would try is replacing all fan-outs with triggers.

In legato-mrn.pd, the fan-out is only going to cold inlets, so this one is fine.

@morpheu5 Your clones are identical. There are two incoming messages that change their operation.
[next $1( and [r $1-grainSpeed].
But [s $0-grainSpeed] sends to all of them so they all have their speed settings changed at the same time as a note is played (except that they do not without the "cursed" bang..)

With the cursed bang they are all updated for an incoming note...... but all the [vline~] are restarted causing an overload.
Without the cursed bang none are updated until the metro bangs again....... but there will be an indeterminate delay until the metro bangs........ during which time the tail of the previous grain will still be playing the previous note..... and then none of the others will be updated......

Assuming you want all the grain tails to be updated by the note but not be restarted..... (that is how it looks at the moment....... Monophonic.... if not then everything below is untrue).......

........ you will need to bang [vline~] only from the [next $1] message and modify the output of [vline~] before [tabread4~ $1-grainData] with a [x~] for all the other clones..... the value for the [x~] being the relationship between the current and the previous note.

..... And the new note needs to bang the [next $1( message...... not the [metro]

BUT you will not want the multiplier for the newly banged [vline~]....... and your clones are identical...... aargh.

SO in fact you need to get the grainSpeed into the clone as a modifier of the output of [vline~] and not as part of it's received message (so that they all change)....... and only bang one clone to restart one [vline~] at the same time through the [next $1] message..
Doing that you will only need to set the modifier as a value for the note and you will not need to mess around with relative values between notes.......
I think that is it in summary.....
David.

@whale-av Aha, thanks! I think I'm moving forward a bit here! But also a bit backwards.

So, I got out of the "last pitch" issue, that's great. Here is what I achieved so far: granular_20.zip. I'm throwing in one of the samples I'm using to demonstrate why I'm going backwards.

First, though, I get clicking between notes when the [legato-mrn] patch does its job (it's more noticeable with quieter samples and I'm sure it also happens with staccato notes but I haven't been able to hear it. Anyway, I figured I'd put another [vline~] right after the grainSpeed bit but I'm getting some horrible zipping noise (which I suspect is just a slower version of the clicks).

Second issue, higher notes start later in the sample, so basically the higher you go, the closer to the end of the sample you start playing from. I think this is related to the way I'm modifying the output of the grainData [vline~]. I'll play around with it a bit more but if anyone can spot an obvious solution, I'll be forever grateful at this point

(no pressure, but I'm hoping to use this one in a video that should be out in about 48 hours, so… and I'll also try to make this polyphonic, by cloning the granular patch, let's hope I don't kill my PD!)

EDIT: Ok, scratch the second issue, I had a day-long brain freeze that thawed only now. The first issue persists but now that I have it running polyphonically it's not even that bad.

@morpheu5 @whale-av is right, you need to get the grainSpeed into the clone as a modifier of the output of [vline~]. My comments from yesterday were not well thought out.
Spoiler: one way to do it grain.pd

Right, so, to "conclude", here's what I have so far: granular_30.zip. I'm also throwing in the patch to make it polyphonic. Unfortunately, on my machine I can only run 4 voices polyphony, each composed of 8 grain clones, and only by increasing the block size to 256, which isn't even that bad.

If I try to increase the polyphony by even only one voice, or the grain counts by one, I get quite a dramatic deterioration in quality/performance and a stupid amount of latency. Have I reached the limits of the engine this easily? Not that I really need more for the moment, but it seems like a pretty dramatic limitation for a granular synth, at least one done this way.

@morpheu5 you could reduce the amount of oversampling, is there a reason for oversampling by a factor of 16? And you can [X] - switch~ off grains that are not playing..