I am trying to comprehend why samples and plugins have the ability to share an instrument slot.
Only real practical use i can see in this is being able to trigger a sample under/over a plugin although ironically it doesn’t even seem that practical.
The new Properties panel in R3 b6 now displays macro’s which is sample specific however if i dedicate one instrument slot to a plugin then what is the point
in having macros? Is this a little contradictory?
Which brings me to a query of an older post of mine:
This idea sits around having dedicated instrument slots per track/pattern effect columns which could eliminate a certain level of confusion and contradictory.
Also would it make sense if the instrument properties automatically hide macros if there is no sample present? Only because you have a redundant function at present - enabled or not.
This is the way it has always worked. But you can argue that the more powerful the sampler becomes, the less likely you are to stack a VST on top of a sample instrument.
However, instead of trying to separate plugins and sample-based sounds, I think we could investigate the ability to stack sounds even more. Most samplers have hybrid playback modes, in which you make several sounds play in unison. This is powerful stuff, and having the instruments logically organized (UI-wise) in the same spot makes sense IMO.
Perhaps this is where a tree/branch-based instrument list would be helpful to disambiguate entries (not completely flooding the list as showing a list of samples could/would)
well, it is very handy feature, i use combination of sample and vst instrument very often, you can make very insteresting layerings…
you can here in this track when pulsating pads acures there is a layering of vsti and sample (in the middle of the track 4:10 min all those two pads are in one instrument, i made that when first note plays you can hear only vsti but when new note hits than you can hear note two of vsti but note one of a sample its laike a delay for each new sample) , https://archive.org/download/MigloJE-Linear_Emotions/kahvi163c_migloJE_gighaa.ogg
“Always has been” but thank god we can advance!
With consistency, efficiency, natural reactions and comprehensibility in mind can we consider these:
Currently you cannot process a plugin and sample separately if they share the same instrument slot. Edit: In addition - If samples and plugins were to combine, they should run in parallel to allow for separate processing.
Sure we might have some flexibility in future by sending to multiple fx chains type methods but
would this potentially mean dev would do something like this Combine Sample and Plugin tabs.
To me - Hybrid means multiple types of things wrapped in ONE. A practical example of a hybrid instrument slot would be
double click on the instrument slot then Renoise switches to a single “Instruments” tab which has incorporated control over both plugins
and samples loaded to that slot.
Some inconsistencies:
If you double click on an instrument slot that only has a sample; Renoise then goes to the Sampler tab yet if you double click an instrument
slot that contains both a plugin and sample; Renoise’s priority is to open the plugin editor - Renoise decided for you but maybe you wanted
to see the sampler tab OR… maybe you wanted to see incorporated controls for both in a single tab?
As of b6 we can choose to load a plugin in one of two places being the plugin tab and the new instrument properties panel.
Why do we even have a plugin tab when we can do almost everything in the instrument properties panel? I think the panel
could have been more efficient if it replaced the plugin tab to perform global commands over any loaded plugins
or samples in a selected instrument slot. Is this a double up? Can’t be efficient if so.
We now have 6 possible controls per track of which we can manipulate volume:
Pre fader, post fader (also linked to mixer fader), DSP’s, plugin editor, sampler tab, plugin tab, and now the instrument properties panel.
How many do we actually need? If not as many then how many are redundant functionality? Plugin and sampler tabs merged could efficiently
reduce it back to 5.
The new Properties panel in R3 b6 now displays macro’s which is sample specific however if i dedicate one instrument slot to a plugin then what is the point in having an option to display macros since it’s only sampler specific? Simply hide it you say? I say what a cheap workaround.
Yes the “Tree or Parent - Children” concept could work well! It would be quite efficient, consistent and fully usable.
Yeah, macro should hide and program change should appear dynamically. Something “like see macro / vsti program” posibility… (I realize you can combine vsti with samples so you might want see macros and not vsti program, but it is imho rare ocassion and macros can be still influenced by two ways (in detachable inst. editor and by dsp device). Changing program just by one, so it (programs instead of macros) should be preffered in this situation imho _ or posibility to display both macros and program but i dont think it would be elegant sollution).
And that stacking of samples and vsti doesnt bother me anyhow, it is just feature.
The fact that the sample name is hidden by the overlayed VSTi name is a bad thing. You need to be able to see the layers or the overview is misleading.
“Features” like this are released with inconsistencies but must admit they have some type of workaround sometimes for certain things - which sadly is not a solution.
I would love to see features released that are fully functional, are consistent, 100% usable and are efficient in workflow. Otherwise not worth releasing until they are 100% thought out.
