Nothing complicated.
I guess it's so easy that i did' it partially with a simple cycle actions.
What the Cycle Action lacks is "parametrization" and customization of some things that can vary from session to session.
I'm pretty confident this can be done with a script or an extension (i'm not a programmer so i'm not 100% sure, i can only partially deal with Kontakt KSP).
It's a very simple task, but very time consuming to set up.
What we ask is a way of setting things fast and easy without the hassle of the time consuming task of modify a template to suit every specific session.
For example, could be cool to configure a session in a simple pop-up window that asks:
- Are you going to sample an acoustic or midi instrument?
> if midi, ask for note duration, how many notes per octave to sample, how many
velocity layers, how many RR (if needed) what midi port to use, generate midi events to be sent.
> if acoustic, ask for average sample duration, how many notes, how many
velocity layers, how many articulations, how many RR AND generate Markers and
Punchers and Streamers (as in the useful script from Xexano) as visual cue
with text suggesting note to play, dynamics to use, when to play ecc..
At the end of the recording process process, name each items with a scheme
- $track_articulation_vel_note (for example) -
Then run an action to split when the signal is over an user defined threshold (with lead and trail pads and relative xfades), create regions from items named as the items them selves, run an action for endless loop (in the style of my cycle action or maybe a better one with sample reverse?) and create overlapping regions, relative to the looping portion, named "#loop" to embed looping metadata in the render process.
After that leave to the user the "quality check" and adjustments for loops and sample start and the final render.
I guess it's not overly complicated (as a concept) and for sure all of this stuff is time consuming to be set manually or by modifying an exixting template especially when dealing with very large projects involving to sample every note, a lot of velocity layers, round robins etc..
And BTW a FR is a suggestion to the developers, not an impositions from the users.
They will probably never consider this FR, but we are here to keep our hopes high, because is the only thing we can do about it