@ustk Wow seriously impressive work here! Excited to dig into this.

@d-healey This is the only mention of "linter" on the forum so far :D

I know nothing about how much effort implementing a linter would be, but even the low hanging fruit would save me a lot of development time. Yesterday I spent ages debugging a condition where I accidentally went if (var = 2) instead of if (var == 2).

I assume the ideal solution would be to adapt an existing linter, but maybe there's an easy way to do some basic checks until then?

Hence the feature request :-) fadeComponent has been working very well for me so far, it would just be great to have a quick and easy way to achieve fades to semi-transparent states like this.

@Oli-Ullmann thank - I already have a work around - what Im asking for is a post-init callback - as David did right at the start of this thread.

@Christoph-Hart not sure I follow

9cce4a7f-9ebc-44a8-be68-9835d0325fc3-image.png

I changed the range on the Value parameter to 0-0.1, it still outputs the raw value to minmax value.

Even so, it's still not dynamic.

I think it's just a missing node, what are the odds of using it in a signal path instead of using it to cable things around? Dynamic range adjustment, that's it? It's much more likely to be used in the context of pma, cabletable, inputToggle which are the workhorse nodes for value manipulation when creating modulators.

Overall there's a workaround, so it just depends on how much time this takes you to do. This is just a QoL request.

@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" 🤣

@DanH Digging this back up as would be a lovely addition going forward @Christoph-Hart 👼

Too many vsts have a chaotic automation list.

@VirtualVirgin Agree!
+1

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