@Christoph-Hart found the culprit:

// if this is non-zero it means that the buffer coming // from the DAW was split into chunks for processing // so we need to update the playhead to reflect the // "real" position for the given buffer if(offsetWithinProcessBuffer != 0) { newTime.timeInSamples += offsetWithinProcessBuffer; newTime.timeInSeconds += (double)offsetWithinProcessBuffer / processingSampleRate; const auto numSamplesPerQuarter = (double)TempoSyncer::getTempoInSamples(newTime.bpm, processingSampleRate, 1.0f); newTime.ppqPosition += (double)offsetWithinProcessBuffer / numSamplesPerQuarter; }

@d-healey We really need some new samplespeak words for "legato" and "release" that don't have such ridiculously large overlap with other adjacent concepts.

I put forth "glithe" and "fradeaway" for your consideration.

As in

"Let's re-record that C# to D# glithe transition"

"When the user lets go of the key, we play a fradeaway sample"

"Denoising fradeaways is a massive pain"

"We spent five days recording 800 bespoke trombones playing three octaves of bespoke glithe samples"

I expect these will be a massive success, ambiguity when discussing samples will be eliminated, think of the time savings!

@CyberGen While we're at it, typing a string in the Component Browser could reveal components with that ID.

@paper_lung

I did, but it's not optimized. I'm planning on revisiting it at somepoint.

@Christoph-Hart Hey boss, I might need more than 16 here (32; is it always power of 2?). Can I please trouble you for a preprocessor? What would be the implications of this, performance wise?

Something occurred to me. If we adjust the start time of our sample, then the timeline doesn't make much sense because it always goes from 0. So in the branch I'm working on I've adjusted it so it always starts counting from the start position of the sample - any downsides to this approach?

efbc6c31-5459-4025-8352-9eb73b3fdc9a-image.png

@Christoph-Hart said in Scriptnode File Player and Round Robins:

nah, that's a different topic :)

Damn, my cunning plan didn't work 🤣

@Straticah Yup the table editor needs a big upgrade imo.

@Christoph-Hart dude you gotta redefine your meaning of "this is complex and will take me a while" 🤣

@VirtualVirgin Agree!
+1

@ulrik Oh that's a cool solution, thanks!

@aaronventure I would expect it to work in the same way as component value broadcasters and component control callbacks. - I've never tested which triggers first. I think after the callback would make the most sense.

Edit: I just did the test with the value broadcaster and it fires before the component control callback, but I think for MIDI messages it makes sense for the callback to fire first - although I haven't given it much thought.

@d-healey OMG I was just looking at that…that would be dope.

@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.

@Simon yup https://github.com/christophhart/HISE/issues/432

@griffinboy you should use the unscaler node. So, your script controls the network parameter, which goes into an unscaler node, which goes wherever. It then sets its target to the raw value, ignoring range and skew of the target.

@clevername27
Good to know.@d-healey has no problems either. Maybe I shouldn't worry so much and just write to the User VST3 folder... Thanks for your feedback! :-)

@Dominik-Mayer To be honest, I don't like that the titles of unread posts are underlined, because it clutters the look unnecessarily.