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

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