[feature request] Working with lots of groups
-
@Christoph-Hart that's true, but doing any kind of work in there in the first place is troublesome if you have more than 10 groups.
Importing is also super weird if you want to allocate samples to groups directly.
So the experience becomes trying things until they accidentally fall into place. Any kind of tweaking after the fact can fuck everything up, or at least thats how it feels like.
The sampler interface feels like the oldest part of the entire app.
The "revert monoliths" is also suspectly missing given how it's just a change of a number in the sample map xml, but having to go into the xml and then reload the whole thing just to be able to work with raw files again is silly.
It's not a deal breaker for me because I did manage to do what I wanted in the end (don't remember how but once I get to the point of having to go in there again, I'm sure I'll figure it out).
But I'm one persistent son of a bitch, so I don't think the decision should be based on the fact that me and some others did in fact wade through. Who knows how many didn't.
The sampler UX is bad, in ways broken, disencourages experimentation and tweaking, and as such should definitely be on the top half of your to do list (in my humble opinion).
Frustration builds up, it doesn't just go away. You're right in saying that most of the time is spent in the scripting workspace but that's got its issues too, namely the "forgetfulness" I talked about some months ago, which becomes a serious daily pain on larger projects:
- switching scripts in the drop down should remember which line of code was the last one open to
- midi editors and script modulators should remember which tabs were open and at which line when switching between them
- projects should remember these setups per preset
I did read the Hydra tabs thread but I received no response when I asked about why not store these in a json in the project directory and then load the new tabs when they should be loaded (on opening the processor in the workspace) using the same callback that executes when you double click a compile error, as that properly opens a new tab and at the correct like at that.
Sorry about the minor digression but it ties into my UX point.
-
Here's an example of where a good group list would be very helpful
There are some missing samples in at least one of my 35 groups. So I'm going to have to keep opening that right click menu and going through the groups one at a time until I find them - unless you know a faster way?
Also, here I'm just looking at group 16, but...
-
@d-healey Yes
-
I have 48 groups now :crying_face: :loudly_crying_face:
Libre Wave - Freedom respecting instruments and effects
My Patreon - HISE tutorials
YouTube Channel - Public HISE tutorials -
Working on a project now where I have about 15 sample sets - each is a separate articulation for the same instrument - sustain, staccato, tremolo, etc.
All will use the same modulation chain, envelopes, effects, etc. and I manage RRs from my own script.
I'm seeing no benefit to using more than one sampler at this stage and would like to just separate the different articulations by group. However this is going to require a lot of groups and the group management in HISE is really bad when you have lots of groups. So now I'm thinking to use more samplers just so I don't have to deal with the group system...
I'd still really like to see a group table, with the ability to name groups - I know Christoph that you suggested this is misusing groups, but I think it's just using them. The alternative is misusing samplers and having to manage multiple identical modulation chains which goes against the DRY principle. Or maybe there is some advantage to using multiple samplers that I'm unaware of that makes it worthwhile?
-
@d-healey Are you absolutely relying on velocity in the maps? I personally found that I can cram a lot of artics into a single map just by giving up velocity, a 128x128 map can handle 15 articulations where each one has 8 RRs. You then ignore the incoming velocity and use the artificial velocity to pick different round robins.
-
@aaronventure Yeah I do that kind of stuff too for some instruments.
For this particular instrument, a dulcimer, all the articulations have dynamics controlled by velocity so the simplest solution is map each dynamic to its own velocity range and stick a velocity gain modulator on the sampler.
-
@d-healey if the groups are the issue, then it's not simpler. Lay it all out into a single or few groups with 1 sample per velocity, write out the constatnts about the velocity numbers where you mapped which articulation, and then ignore the note after storing it's velocity. Use your algorithm to play the correct art/rr sample and use the stored physical velocity to send event data for that id which you can use in modulars exactly as if it were a velocity modulator, or take it into scriotnode and do whatever you want.
Your modulator workflow remains the same, but your group troubles go away.
-
@aaronventure Using groups is much simpler than the velocity option. The groups aren't the issue, it's the group management ui in HISE that makes it cumbersome to work with.
I should also add that the samples have been named in such a way that it makes it very convenient to drop them in to the sampler and use the auto-mapper, to map them to velocity instead would require a lot of manual shuffling around. I also avoid a lot of extra scripting using the groups the way I am.
-
@d-healey true, your sample naming scheme would have to change for the automapper to map them properly to the velocities instead.
The sampler UI is problematic yes. I haven't been long enough to know for sure (and I don't feel like building old commits just to check), but it feels like the oldest part of HISE (it's in the name, after all), it really does need some love. It's the only part of the whole dev experience that is below Kontakt's /UI.
I know what I suggested are just band aids and not solutions of the root problem.
-
@aaronventure said in [feature request] Working with lots of groups:
It's the only part of the whole dev experience that is below Kontakt's /UI.
Yeah I'd agree on this, although Kontakt's group management is pretty bad too, but it does have the group table in the monitor window which is basically what I'd like to see in HISE.
