Instrument Design problem.......

[Lindon]

So I have an instrument design problem....

I'm implementing a per-note modulation system: for each sampler in my system - each time a note arrives I look up the next value in an array and set the target effects parameter. I am aiming to modulate Gain, Pitch, and Filter freq.

I set these new "FX Params" in the interfaces on note call back.

This all works, but.......

I have a timing issue: the note passes to the sampler and it begins to play before the FX param change has completed. So this produces an audible effect, for instance if the previous note had a loud gain setting, and the new note has a quiet one, the new note begins to play at the old setting before moving to the new setting giving me a nasty audible click.

So I need to not start the note until these FX changes have completed, and for the life of me I cant think of a nice way to do this....

So the ugly ways to do it....

1. ignore the incoming note and then use a fixed length timer to duplicate the note event.... now I have to manage publishing some fixed delay time to the DAW- with no g'tee everything is done...

2. Publish(use Globals - ugh!) each modified value for each FX param, use a while loop to make sure the target samplers FX params are currently == the published value....

3. use Message.delayEvent - with no g'tee everything is done...

Anyone got any better ideas???

[David Healey]

@Lindon There is a note number modulator you can put in the modulation chains, would that solve it and avoid scripting?

@Lindon said in Instrument Design problem.......:

I set these new "FX Params" in the interfaces on note call back.

If you do need to script it I'd put this stuff in a separate MIDI processor and leave the interface deferred.

[Lindon]

@David-Healey said in Instrument Design problem.......:

@Lindon There is a note number modulator you can put in the modulation chains, would that solve it and avoid scripting?

Sadly I dont think so, its a drum player, so the note number is the same for every incoming note,

@Lindon said in Instrument Design problem.......:

I set these new "FX Params" in the interfaces on note call back.

If you do need to script it I'd put this stuff in a separate MIDI processor and leave the interface deferred.

Yeah once I have it working I will attend to that...

[David Healey]

@Lindon said in Instrument Design problem.......:

Sadly I dont think so, its a drum player, so the note number is the same for every incoming note,

Does it have to be?

For gain and pitch you can change these on the individual events instead of using an effect or modulator.

[Lindon]

@David-Healey said in Instrument Design problem.......:

@Lindon said in Instrument Design problem.......:

Sadly I dont think so, its a drum player, so the note number is the same for every incoming note,

Does it have to be?

For gain and pitch you can change these on the individual events instead of using an effect or modulator.

Yes thats true, i might look at doing that at least for these values, it still leaves me with Filter Freq and FM depth (its a scriptnode Faust effect), but it should improve things, thanks.

[David Healey]

@Lindon If it's a custom effect could you implement the MIDI handling directly inside it using MIDI nodes?

[Lindon]

@David-Healey said in Instrument Design problem.......:

@Lindon If it's a custom effect could you implement the MIDI handling directly inside it using MIDI nodes?

perhaps, not sure that will solve the delay problem, but itas not so problematic on the FM side so I will look at it... thanks again.

[dannytaurus]

@Lindon Claude says:

The delay is not the real problem. Two things are going on: the interface script is deferred, so its onNoteOn runs after the note has already been rendered, and Gain / Filter are shared effects with parameter smoothing, so every change ramps from the old value and also ramps the tail of the previous hit. Per-note values on one shared effect can never be clean while drums are still ringing.

The per-voice route avoids all of it:

1. Put a Script Processor in the sampler's MIDI chain (not the deferred interface). It's onNoteOn runs on the audio thread before the sampler sees the event. For gain and pitch use Message.setGain(dB), Message.setCoarseDetune / setFineDetune. They are baked into the event and applied at voice start, no ramp.
2. For the filter (or anything else), use the Event Data Modulator. In the same MIDI processor:

  const var rm = Engine.getGlobalRoutingManager();
  function onNoteOn()
  {
      rm.setEventData(Message.getEventId(), 0, nextValue); // slot 0, 0..1
  }

Then add a polyphonic Filter to the sampler's FX chain and an Event Data Modulator (SlotIndex 0) in its Frequency Modulation chain. The value is captured when that voice starts and never touches older voices. Set DefaultValue to something sensible (it is 0% by default), or make sure every note-on writes the slot. The same modulator in the sampler's Gain and Pitch chains works if you would rather keep everything on one mechanism.

Timers, delayEvent and polling loops all add latency and still leave the previous hit on the wrong setting.

No idea if that's useful, but since you don't use Claude I thought you might want to see it's input.

[David Healey]

@dannytaurus said in Instrument Design problem.......:

the interface script is deferred,

It isn't Claude.. or is?

[Lindon]

@dannytaurus thanks, sadly Claude has it wrong as the interface script isnt deferred and point 1 was Daves idea so thats worth a try, point 2 is interesting never thought of doing it this way might give it a go, tho my knowledge in this area is very very limited.

thank again.

[dannytaurus]

@David-Healey said in Instrument Design problem.......:

It isn't Claude.. or is?

What do you mean? I just asked Claude to read the post and suggest a solution.

[Lindon]

@Lindon ok so heres my first question:
assuming Im attaching to Filter frequency using index 0, what do I put in nextValue, can it be a normalised value or does it have to be in the applicable range (20 ->20K )??

[David Healey]

@dannytaurus said in Instrument Design problem.......:

What do you mean? I just asked Claude to read the post and suggest a solution.

Claude stated that the interface script is deferred, when it isn't. There is nothing in this thread to indicate it is but I'd figured from Lindon's post that is isn't and Lindon has confirmed that now.

I find Claude (AI in general) makes assumptions and states them as facts. That wastes tokens and waste my time chasing down an empty rabbit hole.

[dannytaurus]

@David-Healey Yeah, all AI models make mistakes. I often challenge anything that doesn't sound right. It will just apologise and course correct.

[dannytaurus]

@David-Healey said in Instrument Design problem.......:

If you do need to script it I'd put this stuff in a separate MIDI processor and leave the interface deferred.

Claude may have picked it up from this line. I had it read the whole topic, not just Lindon's original post.

[David Healey]

@dannytaurus Yep that's the way. The problem is if you don't know that what it's said is incorrect you can't challenge it.

@dannytaurus said in Instrument Design problem.......:

Claude may have picked it up from this line.

Yes, and in context I'm suggesting to Lindon that he defers his non-deferred Interface script and instead uses a separate non-deferred MIDI processor,

[dannytaurus]

@David-Healey

The problem is if you don't know that what it's said is incorrect you can't challenge it.

Same as humans. And the HISE documentation, for that matter!

[griffinboy]

@dannytaurus
For this reason I only ever use AI to advise with code, if it's something with an instantly falsifiable result (eg. that math was supposed to result in a flat frequency response, but we measured ripples, therefore it failed). Making it reason about abstract problems and solutions still performs very badly in the absence of good measurement tools to determine sucess.

Actually, even if an Agent is in a good feedback loop where it can run the code in question, and check the result of its idea, I've found that it still ends up cheating the problem and writing the code in a way that will come back to bite you later, even if the immediate answer is correct.

Perhaps it will continue to improve, the advancements in this field have been speedy indeedy.

[dannytaurus]

@griffinboy Respectfully disagree. My experience is overwhelmingly positive.

Context:

I code with agents 3-4 hours every day, often longer, and I only use the best models available.

With respect to HISE, the agents have access to the full HISE and JUCE source code, the documentation website, the MCP server and CLI tools.

The rest of my work with agents is on Ruby on Rails web applications, static websites, business intelligence and planning, and brainstorming. Quite a wide range.

[griffinboy]

@dannytaurus
That's interesting!
Maybe we are working on different kinds of projects?

I've been using GPT Astra Max, for DSP science. And I've found it to not be "clever enough" with it's coding. Part of the problem is likely that a lot of DSP solutions are proprietary and so there is a gap in it's knowledge, but even when I supply the solutions, the code (or advice) produced, is short sighted, and blocks off many quite important optimizations down the line if I were to take it's advice seriously.

And without a very good measurement harness (super-resolution frequency response, phase, sidebands, etc), it wasn't able to QA audio properly either to realize that its solution was nonsense.

It's the kind of thing where I think many people would take it's word for it as well.