Lunacy Audio presents CUBE

[DimitrisSP]

Great Work at all levels! I wish great success!

[lalalandsynth]

wow...just wow, very inspiring.

[UD AUDIO]

This what I call audiovisual experience..
Not from earth!

[Sawer]

Congratulations man. Really outstanding! Please can I ask you made the sample editor in the GUI ? Thanks

[A Former User]

I'd love to learn more about the Orbits system, are they made using Timers? Have you encountered any stability issues with Orbits in the compiled plugins? I'm working on something similar, but far simpler for my player, it's a lot of fun :)

[Casey Kolb]

@nesta99 Thank you! Are you asking who designed the sample editor or how we programmed the sample editor?

[Casey Kolb]

@iamlamprey Yup! The Orbits system is only timers and so far we haven't had any stability issues related to the Orbits system. We're running a fast timer in the onTimer callback. The key for us was to really optimize any calls in the timer because every extra call can bump the processing up substantially. Use local variables, don't create new objects, avoid unnecessary API calls, etc. Also you'll want to make sure you set Synth.deferCallbacks(false) so that the timer is in real-time and not deferred.

[DanH]

@Casey-Kolb I find the deferCallbacks thing confusing. Can someone point me to a situation where you do want it and one where you don't want it? And why :grinning_squinting_face:

(I know there's an example above but how would the timer being deferred actually impact real-world usage)

[d.healey]

@DanH said in Lunacy Audio presents CUBE:

@Casey-Kolb I find the deferCallbacks thing confusing. Can someone point me to a situation where you do want it and one where you don't want it? And why :grinning_squinting_face:

If you want to update the UI when the user presses a key but you don't want it to cause latency then you use it.

If you want to change the velocity of an incoming MIDI note then don't use it.

Generally your UI script should be deferred.

[DanH]

@d-healey Thanks David. So any animations I want to leave alone right?

My script is, in the words of the great @Christoph-Hart, " a gargantuan script sausage ".

Assuming I wish to keep it this way (all in oninit) where would I place the deferred command in relation to my animation timers?

[d.healey]

@DanH said in Lunacy Audio presents CUBE:

So any animations I want to leave alone right?

Generally you don't want animations to cause latency so you would defer your callbacks, panel and engine timers are deferred anyway though so if you're using them it doesn't make a difference. It's only the synth timer that runs in the realtime thread.

Assuming I wish to keep it this way (all in oninit)

Is there another way?

where would I place the deferred command in relation to my animation timers

In the on init callback.

[Casey Kolb]

@d-healey said in Lunacy Audio presents CUBE:

Is there another way?

@DanH Are you using a text editor like Sublime? Or are you editing everything in one single file within HISE? The include file call is your best friend here You can make your scripts more modular that way.

[d.healey]

@Casey-Kolb said in Lunacy Audio presents CUBE:

The include file call is your best friend here You can make your scripts more modular that way.

This is the way to go, but everything is still in the on init callback, it just looks pretty and you can work with it like it's all separate.

[ustk]

What do you guys think about having an indicator in the different scripts to see if it is deferred or not?
Could it be a good request?

[d.healey]

@ustk We already have one. You really only need to defer the UI script though, unless for some reason you want to do non-realtime stuff in the real-time callbacks in a script that the user won't see - maybe there's a reason I'm not aware of.

[DanH]

@d-healey @Casey-Kolb Yep need to get my head around it.

I meant everything in oninit as in everything splurged out in the oninit in Hise rather than neatly compartmentalised into smaller scripts.

The issue I have is that so many of my UI controls and callbacks seems to end up in other parts of my script. I'm scared to move them around.

If I use the include file call does it behave like.... script script script (sausage part one), oh here's a include file call lets stick that here in the script, script script script (sausage part deux), oh here' another include file call lets stick that in the script here, and so on and so forth

i.e its more or less sequential

[d.healey]

@DanH That's what coding standards are for - https://github.com/christophhart/hise_documentation/blob/master/scripting/scripting-in-hise/hise-script-coding-standards.md

[ustk]

@d-healey said in Lunacy Audio presents CUBE:

@ustk We already have one.

[Casey Kolb]

@DanH It's as if the contents of that file were right there in the script, but just replaced with that line of code include. Definitely will make your life WAY easier!

In general, it's good to keep UI declaration and logic separated, so you might have different files for declaring different sections of your UI with other script files for their callbacks or other logic you might need. Though I'm guilty of breaking this all the time. It's hard to stay organized I think David probably knows the best ways.

[DanH]

@Casey-Kolb Thanks Casey, makes perfect sense :)