A new mode for switches please

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

  1. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    It seems the primary iterator does its thing between clock cycles. Each iteration is a mathematical process and the timing between steps is related to the mathematical process itself. Therefore the mathematical routine can be written in core. What i don't understand is how each iterations output is heard or accepted in between clock cycles. I have never used the module but it seems in reaktor any input is latched during the next clock cycle.

    In REAKTOR, iteration can be used to generate a large number of events that are processed simultaneously, but are treated as if they came one after the other. This technique is very useful when using Modules which behave like arrays (like the Multi Display)

    From the above paragraph taken from the manual it seems multiple events can be triggered in between the serial clock. This is new to me as I was under the impression all event triggers were processed sequentially after the start of the next clock. Once the cpu has processed the entire ensemble it idles and waits to process the new data on the next clock. Obviously every wired connection has the new value latched in memory during the waiting period.

    Using a switch to detach a wire forces the compiler to created and run a new routing so you can interrupt the process with switches. They are bad news and may eventually be discontinued with the new bundle concepts that turn modules on and off.
     
    Last edited: May 1, 2021
  2. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    1st bold line - This goes back to the idea that if I didn't use switches and someone else did then it could cause errors in my program, would it be my fault that they used a switch if the situations were reversed, no, it would be my shortcoming of not making my instrument work properly in any situation that reaktor can cause.

    2nd bold line - I'm not bothered by this at all, they have their own responsibility to ensure the stability of their own code in reaktor as an overall environment, init's and re-init's, no matter what their cause, are still a part of the reaktor environment that you should "proof" your instrument against.



    No offense but this is kind of a BS answer.

    If you didn't use switches then you wouldn't have to init proof your structure, then someone else's use of switches could cause error's in your instrument, which is lazy.

    If you do use switches then you need to init proof your instrument, which is still lazy because you had to do it, because you used switches to begin with.

    If you don't use switches to turn thing on and off and just take the CPU hit then that's a non-optimized code, which is also lazy.

    If you use primary and core together there is no way to turn off primary processing without a switch, so using primary in certain parts is also lazy somehow...

    This is how you're coming across and it just sounds kinda BS to me.


    You can never really guarantee this, with all the UL builders and all the possible combinations of code objects in reaktor, the idea that someone, somewhere, might make something that doesn't work right in response to init events and it's my responsibility to take this in to consideration when designing my own instruments and limit my choice of building techniques and tools to accomodate for them maybe not getting it quite right is more than a little absurd to me.

    Also...

    Then why wouldn't you recommend that others init proof their own structures even when choosing not to use switches, other things in reaktor can cause re-init's, adding a macro, connecting/disconnecting a wire, combining instruments in an overall ensemble, switches aren't the only cause of init/re-init events, they are a part of the total overall operations of reaktor and are not to be feared but rather accepted and dealt with in a stable manor.



    I don't mean to be rude or personally attacking in saying this, but it seems as though you understand the reality of initialization as a must have/necessary evil of sorts in this type of a program but then you have this idea that we shouldn't just accept that and work with it properly as opposed to limiting our entire building potential is some ill conceived attempt at avoiding it.

    The idea that in a program like reaktor I should limit my options and techniques to avoid this occasionally troublesome issue on the behalf of others who may not know how to handle init events in their own instruments is a bit silly.




    So the reality of hardware modules having a few milliseconds of silence/glitches when connecting/disconnecting things, or turning things on and off is acceptable, but not for a few millisecond of time in a software program?
     
  3. colB

    colB NI Product Owner

    Messages:
    3,854
    I'm surprised that you not only admit to this but you seem kinda proud of it!
    You are building and selling software and are happy that it is less compatible than it could be with other software that your users might want to use in combination with yours. Seriously I am surprised!
    You think it's absurd that you might want the software you sell to work better for some of your customers due to better compatibility with other peoples instruments that they might also want to use?
    I absolutely do recommend that people init proof their code.

    The two things are not mutually exclusive - choosing to init proof code doesn't mean that it's ok to use Primary switches.
    The problems are cause by a combination of one builder using primary switches and the other not init proofing their code. Both are at fault.

    I say Don't use primary switches, and Do init proof your code.

    The only difference is that init proofing is an advanced process that is difficult to understand and more difficult to get right, while not using Primary switches is very simple to do and easy to understand.
    One guy saying "its ok to use Primary switches because everyone should init proof their code" is no more correct than someone else claiming that it's ok to never init proof your code because nobody should use Primary switches. Both of these are equally wrong.

    I always init proof my code because some builders are not advanced enough to understand why primary switches are bad.
    I never use Primary switches because some builders are not advanced enough to understand how to init proof their code.

    it's not a zero sum game
    I'm not sure what you are trying to say here, it doesn't really make sense. I fully understand the need for initialisation, I am a programmer. I understand that before running a computer program we need to guarantee that all values and parameters are correctly set in order to prevent ambiguity and ensure correct operation of the program. To claim that in some way I don't 'accept' this or that I'm not working with it is absurd.

    Not using Primary switches is not in any way 'limiting our entire building potential' that is also absurd.
    What primary switches do is interrupt the operation of the program during execution in order to reconfigure and reinitialise the program. That is something that should be considered a last resort in any real time* application. Choosing to do this when there are more appropriate less obtrusive alternatives is bad practice.
    *audio apps on a desktop general purpose OS are not 'real time' in a formal sense, but close enough in the context of this discussion.
    The others on who's behalf you would be doing it are your users. Not sure why that is so difficult to understand?
    If I unplug a cable from one module and plug it into another on my eurorack, there can be glitches due to momentary shorting to ground during removal and insertion of the patch cable. This is something users learn to live with and to work around. If on the other hand, switching a switch on one module caused multiple other modules to glitch, I would be contacting the manufacturer of the module with the problem switch.

    Some bad things are unavoidable, we learn to accept those. Other bad things are avoidable, we should never accept those. The problems associated with Primary switches are completely avoidable - just don't use Primary switches and of course do init proof your code.
     
  4. Big Gnome

    Big Gnome NI Product Owner

    Messages:
    569
    I'd pretty much agree with you if this were the long and the short of it--and in some contexts, this does bear out--but reinitialization can have much more severe effects than a few ms of silence. For example, in addition to the relatively benign momentary dropouts you've mentioned, I've seen GRE's screw up multidisplays, or the operation of mouse areas; they can cause INF or NaN errors; and they can really play hell with memory-based structures including delays and reverbs (who here hasn't hit a primary switch and had a reverb tail "explode" into feedback in response?)--all of which are difficult to predict, diagnose, or fix, and all of which range from slightly annoying to Seriously Bad. You might say these are faults with init-proofing on the builder's part, and I wouldn't argue with that; but it's also so that such issues are caused by event resets, and it's my view as well that, while primary switches aren't the only cause thereof, they're one of the more common ones, and probably the easiest to avoid. So for me at least, doing so falls under best practices.
     
    • Like Like x 1
  5. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    It's not a matter of pride, ego, or dis concern for compatibility, but rather an acceptance that there's only so much in this world that I can control, what and how others choose to build is something I have no control over, the only real control I have is over my own build, all I can do is make sure that my instrument works as advertised in every way possible, while trying to offer the absolute best user experience and workflow that I can provide.

    In some way's that means maximizing CPU efficiency to give the end user more options with less CPU overhead, when it comes to primary modules switches are literally the only option to achieve this, there is no other way.

    If I had a synth with selectable modulator types, we'll say 8 modulation devices, selectable between LFO's and envelopes, each LFO or envelope takes up %1 of cpu system resources.

    That makes 16 modulators, if they are running at all times that makes for %16 of system resources, %8 of that being wasted resources.

    Should I let them all run at all times and just let the user select which one they want to use and not use switches to turn off the unused ones, at a cost of %8 of total system resources, in my eyes that would be the lazy, non-optimal choice to make.


    It's not absurd as a goal, but if sticking to that idea makes my own work less efficient, then I would see that as a failure in my responsibilities to my customers to provide the best instrument that I can at the lowest CPU expense for the most usable instrument on the widest variety of machines, newer or older computers have different specs and power, squeezing every last bit of wasted CPU usage out of the system for a more efficient program is a higher priority to me than worrying about someone else's building preferences.

    Razor uses switches in the master sine bank module to switch between low, medium and high quality setting, and all though Razor is now 10 years old, that is 10 years of a great, powerful and wonderful sounding instrument getting daily use all over the musical planet, without anyone having their project collapse because of a few switches and init events.

    Switches and the init events created by them are not some global level reaktor catastrophe that collapses projects and makes reaktor unusable.


    That's basically my point right here, it's not a zero sum game, primary switches are not inherently bad, there is no singular definitive answer for every possible scenario, every builder does things their own way, beginner or advanced we all have our own bag of tricks and preferred techniques.

    You seem to really dislike switches, I have no problem with them, I find that they are very useful when I want to shut down chunks of core/primary together.

    I've been using reaktor since some time in late 2009 or early 2010, I don't think I've ever encountered a switch/init event that completely broke an ensemble or collapsed my project.

    They don't make things unusable or defective at all.


    It is limiting our entire building potential if you have to limit how many features and what kinds of features you build into your instrument to better manage CPU usage in an effort to avoid init events.

    Don't think like a programmer, think like a musician for a moment.

    There are 2 synths, they both cost $50, they both have equally high quality of sound output.

    Synth A uses no switches, it has 3 single mode analog modeled osc's, 2 env, 2 LFO's and 2 Filters with basic LP/BP/HP 12db types, it runs about %10 CPU on your system.

    Synth B has 3 multi mode Osc's, selectable between analog modeled, FM and wavetable, it's got 8 modulation devices selectable between Env's, LFO's and pattern performers, it's got 2 filters with 20 selectable filter types. depending upon what's turned on and what's turned off it runs between %10-%20 of your CPU.

    From a musician buying a plugin instrument standpoint, synth B is most likely going to get the purchase, it offers more options and sounds than synth A.

    And if the sound cuts out for a few millisecond's while switching modes between filters or modulators, no one really minds.


    This is generally true, but it also relates to switches on system features you might be changing while actually playing.

    Anything I consider a live operation I wouldn't put switches on, but I have no problem with switches on non-playable features, like LFO or env selection, osc type selection etc...

    I can't really imagine too many situations where people would need to switch oscillator or modulator modes in the middle of a note.


    I think we have very different ideas about what it is to look out for the best interests of our instruments users.

    The users of my instrument are the exact reason why I'd use switches, to give them a more feature packed CPU efficient instrument with a deeper more broad scope set of ability's, more power and bang for the buck without worrying too much about cpu overhead.


    I understand what your saying here, but you need to look at a software program as a single module, if you had a eurorack module with 8 selectable modes and switching between those modes caused a few milliseconds of silence while it changes it's internal settings, would you call that defective?


    Not at the cost of making a lesser powerful, lesser featured insrument.

    Switch based init events are not such a big deal as to limit my designs in an effort to avoid them, a better more powerful, more feature rich and flexible instrument with a better overall set of tools more making music is far more important than not having init events, or worrying about someone else's work not being init proofed.
     
  6. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    For me it's a simple question, can I make a better more feature packed and more powerful instrument with lower overall CPU load by using switches to allocate resources where they are needed?

    The answer is yes I can, If the final instrument design and performance are better as an overall instrument, then i am willing to live with the risk that someone else's build might not respond properly to init's and re-init's.
     
  7. Big Gnome

    Big Gnome NI Product Owner

    Messages:
    569
    But this thread is a direct request for the function of switches and initialization behavior to be altered under the hood to accommodate your wish to use primary switches. In this case, it would probably more sensible and definitely more expedient to reconsider your approach with respect to bypass mechanisms, which would also have the benefit of avoiding the reset issues posed by primary switches to boot.
     
  8. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151

    This feature request is about making switches easier to implement across larger macros, not about changing init or re-init events.

    The conversation has admittedly gone way off course and become a discussion about whether or not using switches is acceptable in different builders, which is a valid discussion, but not really anything to do with my actual feature request.

    I'm personally just fine with switches, init and re-inits are just a part of the program, learn to deal with them and they're not a big problem, if someone else's instrument doesn't handle them correctly then they should learn how to do that, just like myself and everyone else here has learned over time.
     
  9. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    I think my reasoning there is the fact that you can re assign the connection of a receive module to a different send or even no send for a particular snap shot. I'm pretty sure they work like that and if they do you can rearrange the connections based on the snaps. This raises the question as to whether a send from a module output after being disconnected from a solo receive will leave it disconnected and the module will effectively switch off. When I say solo I mean there are no other receives connected to the send which can keep it active. Try it and get back with me. It's an easy test. If I remember correctly there is a option "include in snapshots", It must be on for a receive to change what it is connected to. It seems to me a send not connected will break the connection like a switch. I hope so, if it does i may have helped solve your problem. Please let me know what happens, I have a severe toothache right now and don't feel like making a test ensemble for you. Sorry
     
  10. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151

    I hadn't thought of that approach, I'll give this a try, thanks.
     
  11. Studiowaves

    Studiowaves NI Product Owner

    Messages:
    618
    You are very welcome my friend.
     
  12. colB

    colB NI Product Owner

    Messages:
    3,854
    I have no emotional response to switches. I dislike bad programming. I consider using Primary switches that fire outside of normal initialisation context to be bad programming. It's not the switch that's the problem, it's choosing to use it.

    Primary switches come from a different time, when folk were still using single core CPUs running at 266Mhz. In that context is was legitimate to claim that 'this is the only way'. NI like backwards compatibility, so switches are still part of the feature set. That doesn't mean using them is not bad practice.
     
  13. ANDREW221231

    ANDREW221231 NI Product Owner

    Messages:
    809
    i like to oversample my constants before turning them back into events at audio rate, , and after using a step filter, multiplying them with separate event stream, thats when i trigger my accumulator into a modulo to get a serialized index. . this is all to get blue and red flashes on an event table like a night light in the background. it calms me down and helps me concentrate while i work. but i let the accumulator overflow for hours, that parts important i've rigged an fft to run a detection on the looping waveform and detect the extra harmonics when the index finally runs out of precision, cause then the table goes a sort or purple, and i know its time to stand up and stretch

    probably costs a constant 5% of my system resources

    who cares how other people program!! wanna know a real one? this wasn't recent, but once i used the display clock to trigger samples from bandpass filterbank for my critical audio process because it used half the CPU. that actually worked pretty good. i was really thinking to probably take down my horrible second sitar that if i remember right needs to be resets on opening, or the delay line makes a kind of a loud scary spring sound, at least half the time but i think i may actually remain up, with a short dedication your forum handle displayed proudly in the description. i guess you need to modify the actual file and not just the description for it to update in the UL rank though . well that's probably fair...
     
  14. KoaN

    KoaN NI Product Owner

    Messages:
    251
    It might be bad practice compared to your programming, but there's also the fact that everybody is at a different level and we do from what we know,we have limits and/or priorities,time management,etc. And sometimes it's still worth it to bring something to the community even though it's not perfect.
    Maybe at the moment it's simply impossible for him to find a way to optimize that much without switches,maybe he lacks the expertise and will never get to your level?
    I am pretty sure you would consider my creations to be very bad programming as well but i can only do from what i know and i always felt i am not really a scientific person and i do have limits,i am more an artist who can use basic math in a creative way.
    I try to avoid switches but honestly without them i still have initialisation issues here and there and the whole thing is just too complex for me to understand...that whole document on initialisation is beyond what i can integrate,i don't think that can change.
     
    • Like Like x 1
  15. colB

    colB NI Product Owner

    Messages:
    3,854
    That's the point I'm trying to make. Initialisation in Reaktor is extremely complex to fully understand. Two completely different yet interconnected systems - Primary and Core - both being initialised together in multiple passes both with obscure rules that only occur during initialisation. It's unrealistic to expect anyone to fully comprehend that at all times. That's why I think Primary switches are bad practice - they cause re-initialisation during normal operation, which magnifies any initialisation problems.
    With normal initialisation, if you just can't find the source of a problem, you can use some sort of init fade to avoid audio glitches on power up and patch loading. But if you have panel switches that cause re-init, then that will mean dropouts in the audio. Suddenly things go a lot trickier.
     
    • Like Like x 1
  16. KoaN

    KoaN NI Product Owner

    Messages:
    251
    Yes i do try to avoid switches.
    I don't want to speak for Michael but if he doesn't have enough expertise to lower the cpu enough (if possible) without switches that would mean he would have to compromise,remove a lot of possibilities,functions on his instrument and he clearly said he didn't want to compromise on that.
    I guess it's a tough choice to make.
     
    • Like Like x 1
  17. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    It's also a matter of the scale of the instrument, back then people were making very simple basic types of instruments, with today's CPU power comes larger more complex instruments, with larger and more complex options where switches are even more valid to be used.

    Who is it exactly that made this rule that switches aren't allowed?
     
  18. Paule

    Paule NI Product Owner

    Messages:
    7,397
    Myself mostly.
    For Pro-53 Inspiration there is a hold with switch.
    It don't works with selector and button. So the switch must stay there in in Voodoo.
    Michael, that isn't right. Switches produced heavy GRE and some users don't like that.
     
  19. Michael O'Hagan

    Michael O'Hagan NI Product Owner

    Messages:
    1,151
    If refusing to use switches means building a lesser overall instrument, then that is a poor choice to make, I'll use switches to create a better more feature packed instrument.
     
  20. colB

    colB NI Product Owner

    Messages:
    3,854
    Try this switch free hold button? does it work the same?

    EDIT: I didn't remove any of the many other switches - just one 'voodoo' switch ;)
     

    Attached Files:

    Last edited: May 2, 2021
    • Like Like x 1