newbie question

[HughBanton]

Ahaa .. thanks for the FastRelease insight, that does indeed seem to be what's behind getting NoRpt to work. Well found. (And you rescued me from diving right in and creating discord on the good ship Discord ).

And now I think about it properly, the idea of an envelope somehow being able to 'carry on where it left off' is really a bit fanciful in MIDI on-off world. I long ago made NoRpt==true in all my schematics and have ever since managed to convince myself that it was actually doing what I thought it should .. until this!

Big organ-pipe release period is, nevertheless, quite short when compared to, say, piano string sustain. So I guess so long as the typical reverberation period is longer than the pipe release (whether we're talking digital reverb or an actual real acoustic) any overlap between two identical note-instances is going to be pretty effectively blurred. And would only apply to the bottom octave or so anyway, probably not worth going to much trouble.

At least that's what I'm convincing myself for now.

Having said that, another possible direction? I'm wondering about some Ruby MIDI manipulation (.. only embryonic thinking-aloud-type thoughts y'know ..) but possibly if a rapid note ON-OFF-ON sequence arrives - one where the initial ON-OFF period has a duration less than a specified period (shorter than the known release length) - then the intermediate note-off could be cancelled and replaced by sending a MIDI controller, which might be able to manipulate the envelope, get it to carry on as a genuine continuous note?

Except I'd need a polyphonic controller wouldn't I, tricksy. Dunno. I note FS_64 now has a poly MIDI_CC thing, I should investigate This is quite new I guess?

[tulamide]

Thank you Rex, for digging through this!

Just so, that I understand: There is a prim with a switch input. But that switch does only work, when another prim's switch is set to something specfic. And the manual doesn't point to this - I would say - not so unimportant, tiny little detail?

I'm not amused, as the King would probably say in good tradition.

Do all envelope solutions work with the env prim? If not, how to "switch" to NoRpt there?

This prim definitely breaks the rules. All prims I know of are "self-sufficient" (in lack of the correct word) and not dependend on other prims.

[Spogg]

@tulamide: I didn’t know any of what I wrote before I started my “research”. The manual’s description for the MIDI prim doesn’t describe what I found and gives the impression that you could have 4 combinations for the two NoRpt inputs. But I found otherwise, so it would have been better if the manual had provided a truth table or something.

The Env prim will be found in all envelopes which are working in the poly white stream, and are essential for closing the channels which have become silent. I never bothered to look into this before but now I understand what the FastRelease output is for, namely for instant closing of channels and clearing the envelope’s DSP for the no repeat function to work.
In fact there’s another undocumented thing about the Env prim. Where you have more than one envelope generator, when the first (shortest) one has completed it will give a stage output of 5 while the poly system waits for the longer envelope(s) to complete, and only goes back to zero when ALL envelopes are completed. Ages ago I struggled with that until I monitored the Env prim in a real situation. I was using Env == 4 as a test but in that DSP it needed Env >= 4 because of this undocumented output of 5.

@Hugh: For an envelope to start from where it left off the Smooth Retrig has to be set to True and the Hold input to the Env prim has also to be set to True. If the Hold is set to False the channel will close at the instant of note OFF. The Smooth retrig is part of the envelope’s DSP coding and allows the momentary current value to be the starting point for the retriggering. If set to False, the envelope will reset and restart from zero. That will sometimes cause a click due to the sudden change from where it is currently back to zero. This is critical for note stealing when the number of max voices is set lower than that called for.

If you use Ruby in any MIDI processing context, tulamide and I found that a VST won’t render or freeze/bounce properly unless you set the DAW to render at x1 or real time. Something else it would have been useful to read in the manual before I made my SIM-BP!

[HughBanton]

Sorry to have caused puzzlement, and a million thanks for your efforts. Absolutely everyone here must have used MIDI-to-Voices extensively over the years, and never suspected a thing! I don't doubt @MyCo could one day write us a much better one if there was a convincing case.

Anyway I personally don't really have any envelope issues right now, reckon I nailed all that (as far as my stuff goes) a while back. It was only because of my Arduino kb-encoder development that I started to wonder about an alternative velocity strategy, commencing at the upper key contact rather than the lower one, which is what they always do at present. But I'm probably re-inventing the wheel as usual, I do a lot of that .

But I will investigate the poly MIDI cc prim soon, might bear fruit. Finding a way of convincingly re-energising an already-active-running waveform has a lot of appeal to me .. not least because it's something that's near-impossible to get right with the starting portion of samples. Always enjoy getting one-up on sampling organs!

Ruby MIDI; done a lot of that too. I didn't realise there was a DAW issue so thanks for the heads-up. Outside of Flowstone I generally work inside a VST host now (Cantabile currently) and haven't had any insurmountable problems there. I've found the chief thing to watch with Ruby MIDI is to ensure it doesn't get bogged down with things you don't need - kb aftertouch is a typical killer!

To this end I nowadays use a front-end Ruby MIDI 'steering' module I've devised; does all sorts (including velocity handling), splitting notes/sysex/cc etc. so that nothing goes where it's not wanted.

Keeps me amused ... and awake at night.

[tulamide]

If you use Ruby in any MIDI processing context, tulamide and I found that a VST won’t render or freeze/bounce properly unless you set the DAW to render at x1 or real time. Something else it would have been useful to read in the manual before I made my SIM-BP!

That reminds me of something: We now have the chance to get Maik to have a look at that. Could you please provide an example and describe it in the "alpha issues" on Discord? I know that it's not just the alpha involved, but it would be nice if it could be solved for the alpha. In the end it is all about buffering and I think it might be possible to solve.