Long delays (like say 8 bars) not showing up in compiled dll

[Lindon]

So I have a tape delay effect, and I have compiled HISE to accept and work with tempo delays of up to 8 bars (8/1)...

I have a scriptnode network emulating a tape delay... and it uses the jdelay node.

I have set the Limit in these two jdelays to 32000 - so easily enough for most circumstances....

..and, these play nicely - I can get up to 8 bars of delay in my scriptnode, but...

when I compile these into a dll They revert back to being 1 bar or less... anyone else have this issue? Is there some compile constraint being applied(I appreciate this length of delay might chew a LOT of memory..)

..oh I should also say I cant get std fix_delay to be have anywhere with these new longer delay lengths.

[aaronventure]

@Lindon the scriptnode delays seem to have limitations on both ends. Making a comb filter only works up to about an octave above middle C, unless you use frame processing, whereas faust has no problem with any block size.

Try using Faust delays.

[Christoph Hart]

@aaronventure faust uses frame processing by default so that‘s not really a difference.

[aaronventure]

@Christoph-Hart if I wrap it in fix8, it still does?

[Christoph Hart]

@aaronventure not sure how the interpreter works but the generated code consists of a big for loop for each sample so I‘m guessing that it works the same internally.

[aaronventure]

@Christoph-Hart are there any traps if we decide to have different fix block nodes in the network? Can I run some nodes in frame, others in fix8 etc?

[Lindon]

@aaronventure said in Long delays (like say 8 bars) not showing up in compiled dll:

@Lindon the scriptnode delays seem to have limitations on both ends. Making a comb filter only works up to about an octave above middle C, unless you use frame processing, whereas faust has no problem with any block size.

Try using Faust delays.

yeah, except... faust delays use samples, so now I need to add yet another step to calculate the sample rate the user is using to work out the milliseconds required for a calculated tempo setting currently in use - and frankly thats a major pita. all this added to the fact that scriptnodes that include the faust node wont currently compile reliably on MacOS...

[Lindon]

@Lindon well its done - using converter so that was simple enough - thank you - now just awaiting the faust fix.

[Lindon]

@Lindon except it does'nt work in the compiled version!!!! grrrr....

[Lindon]

@Lindon Ok I built a simple test case - and FAUST based delays suffer from the exact same problem - they work fine in the ScriptNode, but compile them and use them in a HardCodedMasterFX and they fail to use the correct delay times...

This requires your HISE build to have the 23 Tempo syncs enabled (so 2/1,3/1,4/1,6/1 and 8/1)....

you can download the entire project here:

https://filedn.com/lbcnNB3zs5mQISH63IOtbfX/DelayBug.zip

This now seems like a bug to me - but I dont know how to reassign from its current category... rereading I guess this is what Christoph was saying 6 hours ago...

[Lindon]

@Christoph-Hart said in Long delays (like say 8 bars) not showing up in compiled dll:

@aaronventure not sure how the interpreter works but the generated code consists of a big for loop for each sample so I‘m guessing that it works the same internally.

I can confirm that wrapping the network in a fix8 doesnt change anything,.it works raw but fails compiled...