A new mode for switches please

Discussion in 'Feature Suggestions' started by Michael O'Hagan, Apr 23, 2021.

  1. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    I see your point, but I'm not really talking about blocks.

    In a larger overall instrument design with selectable modulators and oscillator types switches are a necessity for CPU management.
     
  2. Paule

    Paule NI Product Owner

    Messages:
    7,399
    Laureano in his ilo example. Please take a look there.
     
  3. colB

    colB NI Product Owner

    Messages:
    3,854
    I use blocks as an example because they are the best example of recent work by NI that I have access to.
    Maybe someone who has them can say if NI's most recent 'powered by Reaktor' products use Primary switches or not?
    No, they are not a 'necessity'. They are one option, and IMO, the least favourable option.

    If a project is so large and resource intensive that the only way (all other options exhausted, fully optimal algorithms employed etc.) to make it viable in terms of cpu usage it to use Primary switches, then it's probably something that should be coded in C++, or shelved until cpu performance catches up.

    I suppose I'm coming from a product design angle. If someone wants to use Primary switches in a personal project in some very specific context, then it is up to them if they're happy with that compromise, but creating a 'product' that is going to be used by others in ways the designer possibly hasn't even considered, in a context where it must work well with other products designed by other builders... in that case, Primary switches are a liability.

    We should all build our instruments so they handle soft resets as gracefully as possible, but we can't assume everyone does - its often far from trivial to do so. And if some random effect in an ensemble glitches out when the user hits a selector switch on your instrument, who do you think gets the blame?

    Heavy processing at initialisation time is legitimate... causing unnecessary initialisations at other times, not so much...
     
  4. colB

    colB NI Product Owner

    Messages:
    3,854
    Is this a finished 'product' intended to work with others in an ensemble context, or is it a quick demo where compatibility is not important?
     
  5. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    Mike, you do realize the sends and receives are snap shot sensitive ,
     
  6. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    Yes, I know this, what does that have to do with switches though, they have no effect on CPU allocation as far as modules being turned on or off.
     
  7. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    I don't agree with this at all, especially the bold part.

    I'm making Scratch Master Pro V2.

    These are my responsibilities as I see them.

    1. Do my best to make sure that every feature in the instrument behaves as expected by the end user, track and eliminate every bug I can find and ensure that my instrument is stable, reliable, fully featured and functional in every way so that the end user is happy and exited with what the instrument does and how well it does it.

    2. Make every effort to create a reasonable CPU usage design, something that will work well both in standalone and in a DAW with other VST's in a larger overall project without killing your computer on the CPU load.

    Shelving it for a few years until CPU's are stronger is definitely not an option when switches were created in Reaktor to do this exact job, CPU resources management of unused components, that's exactly what they are there for.



    Again I disagree, consider this context, you combine my instrument with another from the user library, their instrument does not handle switch based init/re-init events properly, is this a defect of my design? Or did they fail to init proof their own design and code properly?




    Again I would see this the other way around, lets say I use no switches anywhere in my design and then they combine my instrument with something from the user library that uses switches, now when they hit a switch on the other instrument mine behaves incorrectly and looks broken or defective in it's response to re-init events.

    There is no way to know what the end user might do in an environment like Reaktor, they could combine it with anything or just mod it themselves.

    In using switches I have not only minimized CPU consumption for an overall better performance but I have gone through and init proofed my entire design to a professional level of stability, global init's, re-init's etc... all behave and reset properly and without errors, if someone else's instrument does not, then I see that as a shortcoming of their design, not mine.




    I don't think that re-inits are an issue in that way, If you build it right it's literally a few milliseconds of time for the whole process to take place, most users won't even know what an init/re-init is, my design is built to handle them properly, I see that as my responsibility in developing a commercial instrument.

    Worrying about the user library instruments or any other Reaktor based program that might not handle switches properly is not really my concern.

    Just for the record, Skanner XT, Razor, and Molekular as use a decent number of switches, these may be a little older, but I'm just saying that using switches in no way shape or form constitutes and inferior or un-prossional instrument.

    When and where they are the right tool for the job then use them, but only when and where they are the right tool for the job.
     
  8. colB

    colB NI Product Owner

    Messages:
    3,854
    A couple of points:
    #1 a few miliseconds of time is a LOT of time on a modern computer. anything that is taking a few milliseconds of time is a major problem.
    #2 there are some major issues with generating re-inits during audio playback situations that you have clearly overlooked.

    here's an example to consider:

    Modern plugins often have complex GUI components that are responsive to user input.
    Often these GUI components are not cheap to update in cpu terms, even if you only update them on the display clock, it can be too much - if there are 10 different fancy displays, each using >100 multi-diplay objects, and running a complex filter process per object per update... yeah, too much.

    The solution is to update them in response to user input, then only one would be updated at a time because the user can't twiddle more than one knob at a time with their mouse! so instead of 1000 of those pesky processes at a time, there will only be 100. that's a huge WIN!
    This approach to 'fancy' GUI objects is very powerful in Reaktor. It works well and enables much simpler coding for great looking instruments. Other solutions require significantly more code. More code is a major problem for cpu usage and compile time in Reaktor as you know.

    So this all seems fine except for one major issue - those knobs that can only be twiddled one at a time all fire during initialisation. Now, that's not a massive problem if initialisations only happen when loading an ensemble or a snapshot - users expect potential slowdown or glitches in those situations, but not during playback when they are just hitting a mode switch or a virtual tab on one of the instruments. But thats what happens if you use Primary switches as a lazy way to save some cpu. those switches cause all the knobs in all the other instruments to fire an event, which means all the nice GUI bling that everyone expects these days tries to update simultaneously oops.

    (this same problem can also be true for code that impacts audio not just GUI - when a control change triggers complex processing to populate a lookup table, or update a large set of parameters - this can work fine, but not if all controls are triggered simultaneously)

    It is possible to find workarounds to this, but they are messy, they obfuscate code, are difficult to debug and maintain, and it's not reasonable to expect novice or intermediate builders to find them, or even to fully understand these issues. So those of us that do know better should be ensuring that our code doesn't cause the problem in the first place. We should also be discouraging new user from using the switches that cause the problem. We must remember that the point of Reaktor is that users at all levels can build and modify instruments and that we should do what we can to make this work better, and not use components that cause issues, then just shrug and say its someone else's problem.
     
    • Informative Informative x 1
  9. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    I see your point , but I prepared for those issues, the only thing controlled by switches are things that you wouldn't change during playback and my display graphics are well optimized against these issues.

    Edit: and I don't think of switches as being lazy, the right tool for the right job, switches, that's what they're for...
     
    Last edited: Apr 29, 2021
  10. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    Hi Mike, hope the frizzle frazzle beast has been tamed. Take it easy professor of perfection. Have fun
     
  11. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    I'm not really sure what this is supposed to mean?
     
  12. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    LOL, your ensemble with hundreds of wires.There are other ways to make connections without direct wires . You can use bundles and disconnect one bundle wire that may contain 50 wires. Makes it easy to save cpu like you originally asked about. Frizzle Frazzle is an old expression band road crews use to say when doing a tear down after a show when unravelling twisted wires the performers criss crossed during the show. In other works undoing the mess. Just wanted to recommend looking into the new core connections. See the what is new manual and check out scoped bus, etc

    . upload_2021-4-30_2-0-53.png
    upload_2021-4-30_2-4-39.png
     
  13. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151

    I know about scoped buses and bundles, but those are within a single core cell, not everything is contained within a single core cell.
     
  14. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    ...Not exactly Mike, a single scoped bus can send to several core cells and macros within the cells. Read up a bit on solid and non solid macros. Also many primary modules like oscillators and filters can easily be made in core depending on the proficiency of the core developer.

    ....Staying within the scope of your thread request regarding switches. That can easily be accomplished in core using bundles to carry the Sample rates and the Serial clock not to mention module resets. Thus a master core cell can easily be used to switch between specialized core modules leaving some turned off and not using cpu and others on to process your functions.

    ...As a bonus we can also increase the master ensemble sample rate and divide it in core where low sample rates work well. Plus you now have the ability use the master sample rate to run things that perform better with high sample rates. You can even use 384k as the master ensemble sample rate. Divide it down in your master core cell and you now have the ability to run some modules at 16k and others at 384k and between.

    ....So by simple observations it's obvious becoming proficient in core programming allows a great deal of control and with these new skills we soon discover there is little need for primary switches and fewer primary modules as well.

    ...
     
  15. colB

    colB NI Product Owner

    Messages:
    3,854
    The problem isn't whether you have prepared for those issues, it's whether others have. As I pointed outs, to avoid glitching from Primary switches, a builder needs to know a bunch of tricks and workarounds that are not in manuals etc. There should be no expectations that instruments created by novice or intermediate builders include any of theses workarounds. And not including them doesn't mean that there code is bad or broken.
    So IMO if your code causes there's to glitch when there's nothing inherently wrong with their code, the problem is in your code.

    It's up to the individual builder of course. My personal approach is to do everything I can to protect my work from use of switches in other instruments, and to NEVER use Primary switches in 'production' code outside of true initialisation time...

    It may be possible to completely protect an instrument from the effects of Primary switches, however that's not the issues here.
    You are a commercial builder, so you make some income from your work. So for you it's important that Reaktor has a good reputation, that folk like Reaktor and trust it. Online there is a lot of positive discussiton about Reaktor, but also lots of negative stuff.
    If some producer or other decides to try Reaktor and loads up a few instruments, but is getting glitches in the audio when switching modes, they're not going to do a bunch of research and work out that it's not your fault, it's the other guys, because he didn't employ all the obscure workarounds to protect his code from the Primary switches in your code... Nope, they're just going to decide that Reaktor is buggy and not worth the effort, then maybe badmouth it in online discussions. In that case, everyone loses, you more than most, because your potential customer base gets smaller instead of larger.
    Fair enough, you don't agree with the basic idea that instruments that use primary switches are a liability, so of course for you they are not a lazy option. For me, they are broken, and there are always better ways to optimise, so from my POV, if you use them even though you understand the problems they cause, that's lazy coding.
    They can be a handy tool during development for quickly A/Bing different version of a process. But that's really not the topic :)
    Anyway, it's all moot in the context of feature requests - I would be extremely surprised if this feature was introduced. At least without a complete overhaul of the initialisation process, and I doubt that will be happening soon.
     
  16. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    The bold part is simply not true, there are no bundles or scoped buses traveling through primary, a single scoped bus can go through any part of a core cells structure, but it cannot leave the core cell to go to another core cell.

    I think your misunderstanding certain things here, scoped buses do not travel between core cells, core cells can have inputs, table references and outputs only.

    This part I agree with in principal, but there are actually limitations to core, there is no iteration, there are no event tables that can share data across the global structure, these are 2 things that are a necessary part of my design, so it has to use primary.
     
  17. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    I cannot disagree with this more, I already addressed this in post #27, If their structure is not init proofed it does not equate to an error or shortcoming in my code because mine is init proofed, that is a shortcoming in their code, that's just how I see it.


    This entire thread seems to be you forgetting this exact statement, I need to turn off 3 or 4 core cells with a healthy amount of primary in between them to conserve cpu, there is no other way to do this, only switches do this job, that literally is their job.


    That actually does seem to be the issue here, you say that you are against this feature request and against the use of switches in general because they can cause errors when interacting with code that is not optimized to protect against these errors, but at the same time you acknowledge that init proofing your code is a completely achievable thing in reaktor, and something that the more experienced builders tend to do even if they're not using switches.



    This has been true since before I started using reaktor, and if reaktor's still around, it will still be true after I'm dead, most negative discussion comes from people who just don't like it, the number 1 reason I see people say that they don't like reaktor is because of the layers of complexity in using it.

    Instruments, ensemble, blocks, racks, snapshots and presets can be a bit confusing to some people at the start, that's the #1 thing I see people saying that they don't like about it.


    Back to post #27 my friend, neither you nor I can be help responsible for someone else's instrument not handling init events properly, that is up to the individual builder, and I don't see this as a major concern.

    The larger majority of people who use purchased my instrument and use reaktor generally use 1 instrument at a time.

    For every person who builds custom racks of 4 or 5 instruments as an ensemble there are a hundred who just load up Razor or Monark and just play the instrument.


    From my point of view taking the time and making the effort to init proof my entire instrument is the exact opposite of lazy coding...:rolleyes:

    I'm not worried about interacting with someone else's code here, only that they load up my instrument and get professional and reliable performance.

    So back to post #27, I don't use switches, and someone else does, then I look like I built a broken instrument when I didn't.


    Actually I think it might need to happen sooner rather than later, the addition of blocks and rack's and front panel patching has created a system where init events are happening pretty regularly during patch and play type sessions.

    Lot's of people build a patch, play around for a few minutes and then start altering their patch, save as, alter it more, save as, rinse and repeat until they've spent an hour or two playing with the modular fun stuff.

    This is good reason to look at improving init behaviors.
     
  18. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    ......If you pursue core programming you might be realize these primary modules can also be implemented in core. In other words it may be possible to build you own iteration module. It may not be a prefabricated core library module but if you make one it will be in your personal library. The modules that seemingly cannot be made are modules like midi in and others that are connected to the outside world. Reaktor includes these in the primary library but the outputs can be processed in core. The same applies to event tables. If the table itself does not connect to the outside world it too may be possible to implement in core.

    ......I'm by no means being self centered and demanding you use core, it's just a mere suggestion and it's not for everyone. I've only mentioned it as it seems you've discovered primary has it's drawbacks. There are probably several ways to achieve the same results in core where you problem could have been avoided. Core's limitations are dealing with the outside world. So if your iteration and event tables do not handle outside world info like midi in modules as an example, they can most likely be implemented with core programming. Have fun
     
  19. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151

    I see what you're saying, but iteration is a special case in reaktor.

    you can kinda create your own iterator in core, but it is limited to audio rate, the real primary iterator is designed with a sort of clock cheat, it can go faster than audio rate or control rate and make thing nearly instantaneous.

    I've done a lot of work with iteration and I've custom build iterators in core before, but the audio rate limitation is an issue in several circumstances.

    When the primary iterator is used it can do things faster than control rate or audio rate, it's also an in-built part of reaktor that primary and core inputs can keep up with the iterators faster than audio rate speed, but only for events driven by the iterator itself.

    I don't know if this would be technically correct, but it's like iteration in primary has it's own clock layer and anything being driven by the iterator will speed up to that special iterator clock speed, but only ports and processes being directly driven by the iterator, this is something explicit to th eprimary iterator and nothing else can match that speed and functionality.
     
  20. colB

    colB NI Product Owner

    Messages:
    3,854
    You are right, we can only be responsible for our own code. For me part of that responsibility is to ensure that my instruments are as compatible as possible and causes as few problems as possible in as many contexts as possible. One of the ways I can do that is to avoid using Primary switches because I know that there are a great many instruments out there that can't gracefully handle those reset initialisations. I guess you're not so bothered about that! No biggie ;)
    No it's not - you're forced to do that because otherwise your code would literally be breaking itself :rolleyes:
    I think this is really the crux of this debate.
    You think that as long as it works by itself then it's fine.
    I think that in order to be considered 'professional and reliable' it must work with happily alongside other peoples instruments.

    Yes. This was why I was so disappointed when patch and play was released - the fact that it was an extension of the existing inter instrument connection system means that these problems are baked in. Initialisation is crucial, and it is impossible to make all initialisation situations fast enough to guarantee glitch free changes to the structure.
    The only way to fix this would be a complete change to patch and play so that the front panel connections are a separate tech from normal interconnects. That might be possible as they are instrument to instrument connections. But then if that change was made, there would be no possibility to have patch and play connections internal to an instrument, which is another requested feature.
    In general though, I think users are less likely to have a problem with slight audio glitches when rerouting patch cables - that is something that even happens on hardware modulars for various reasons.