Instrument Design problem.......

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

[dannytaurus]

@griffinboy Yes, different projects indeed.

I can see agents and models lacking the detailed-oriented work necessary from your work, but it's a stretch to extend the 'false positives' arguments to all agents/models across all work.

In your case, the amount of resources the agent has to refer to is key. Exactly the 'gap in knowledge' that you mentioned.

[dannytaurus]

@griffinboy By the way, do you know that agents will happily decompile binaries now? For research purposes only of course. 'Proprietary' is starting to lose meaning.