Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

MOZAIC - Create your own AU MIDI plugins - OUT NOW!

16465676970102

Comments

  • @Skyblazer I've kinda managed a very basic version, will have to think hard on the next bit, might need to use custom scales or something, not sure but I'll need to look at more of other people's scripts to get how restricting the harp to chords rather than just scales - it works quite nicely at the moment though as I've made the y value control the velocity, so you can emphasise parts...

    Need also to restrict the range or have a slider control that...

    Also thinking about a less precise and more expressive way of forming harmonies might be a row of sliders - most scales are less than eight notes so you could dynamically 'drawbar' scale notes out, adjust as though you were damping them in the way harpists do...

  • @Krupa I like your idea of using the Y axis to control velocity. I think I'll use that for my interpretation as well, if you don't mind. I just finished coding a very basic version, with three strings playing one C chord.

    I'm not really familiar with the harp, so I'm not able to visualize what you're describing with the second paragraph. I'd be interested to see yours. I'm going to have users use the knobs to manually enter the note for each string, for four "chords". Maybe you're talking about doing something similar?

  • @wim: here is a little script to help visualize translate curve and the influence of the bias/curve param

    @OnLoad 
      SetTimerInterval 20
    
      count=0
      //bias =1
    
      SetKnobValue 0, 25.5
      bias = TranslateScale (GetKnobValue 0) , 0, 127, 0, 5 
      LabelKnob 0, {bias: } , bias
      StartTimer
    @end
    
    @OnKnobChange
     if LastKnob = 0
       bias = TranslateScale (GetKnobValue 0) , 0, 127, 0, 5
       LabelKnob 0, {bias: } , bias
     endif 
    @End 
    
    // update the screen every metronome pulse...
    @OnTimer
      if count>127
        count=0
      endif
    
      //x=count
      //y = count
      y = TranslateCurve count, bias, 0, 127 
      SetXYValues count,y
      if count<127
        count=count+1
      else
        count=0
      endif
    @End 
    
  • @Skyblazer said:
    @Krupa I like your idea of using the Y axis to control velocity. I think I'll use that for my interpretation as well, if you don't mind. I just finished coding a very basic version, with three strings playing one C chord.

    I'm not really familiar with the harp, so I'm not able to visualize what you're describing with the second paragraph. I'd be interested to see yours. I'm going to have users use the knobs to manually enter the note for each string, for four "chords". Maybe you're talking about doing something similar?

    Yours sounds interesting, probably more practical than mine, which I might put on PatchStorage so that others can try it (I'll have to check the preset licences first though). Mine's probably a little more difficult to play but might just work, if I can figure out a sensible method of quieting only the notes that you don't want to sound as you strum...

  • @Skyblazer I just switched note playing from @onmetropulse to @onxychange and I'm getting stutter notes, I can appreciate why, do you or anyone else have a way round that?

    I'm also struggling with even starting to quieten specific scale notes, I'm thinking it's a series of if then statements with modulus in it but that seems inefficient - any real programmers got a clue to set me in the right direction? @McD @wim @_ki

    Actually just remembered the discord, maybe someone there...

  • @Krupa If i understood correctly, you wan to speed up your IF-Cascade which filters out specific scale notes.
    You could precompute the 12 (or even 127 if the result differs per octave) outcomes into a simple array containing only YES of NO and later-on just have a single IF like

      if  result[ note%12 ] 
      endif
    

    .
    In the case you need an offset per note or scale-step to ‚adjust‘ to a new scale, you could store the needed offset (including the 0 for NO offset) in an array and later-on just always add the computed offset - without any IF or IF-cascade needed.

  • And as general remark for the ‚Strumming via XY pad‘ idea, i would like to re-mention the idea (of wim iirc) that having an OnXYPadDown and OnXYPadUp Moazic event would be nice.

  • @_ki said:
    @Krupa If i understood correctly, you wan to speed up your IF-Cascade which filters out specific scale notes.
    You could precompute the 12 (or even 127 if the result differs per octave) outcomes into a simple array containing only YES of NO and later-on just have a single IF like

      if  result[ note%12 ] 
      endif
    

    .
    In the case you need an offset per note or scale-step to ‚adjust‘ to a new scale, you could store the needed offset (including the 0 for NO offset) in an array and later-on just always add the computed offset - without any IF or IF-cascade needed.

    Thanks for that @_ki food for thought, I’m still at the point of figuring out the if cascade right now. An array sounds like a sensible proper solution that I can move to once my head is around the basic routine :)

  • edited February 2020

    I've very hackishly set out what I [Roughly] aimed to achieve but it's definitely going wrong somewhere, might well be beyond my limits already 🤣

  • Just trying to upload a patch to patchstorage but it won’t let me - there’s just a red delete button where the file goes... it says below that .mozaic files are supported...

  • edited February 2020

    Wally alert, I just needed a screenshot...

    https://patchstorage.com/myharpx/

    If anyone's feeling dangerous 😁

  • @Krupa said:
    Wally alert, I just needed a screenshot...

    https://patchstorage.com/myharpx/

    If anyone's feeling dangerous 😁

    It's definitely more complex than the first script I wrote!

    It looks like you're using sliders 3 to 9 to set the velocity for each note in a 7 note scale. I would add "Log notenum" after "notenum = ScaleQuantize notenum" to see how you're affecting notenum. It's not finding the closest diatonic scale degree of the triggered note. I wouldn't be the best person to help with that, because none of my scripts have anything to do with scales.

    I see what you're trying to do with the "played" array to fix the stutter notes. Not a bad idea, maybe worth keeping, but I would also check to see if the note being triggered is the same as the last note, and only play it if it's different. And then also, if we get the option to cancel Note Offs soon, you could have it cancel the first Note Off when the same note is triggered twice in quick succession.

  • @_ki said:
    And as general remark for the ‚Strumming via XY pad‘ idea, i would like to re-mention the idea (of wim iirc) that having an OnXYPadDown and OnXYPadUp Moazic event would be nice.

    I agree, that would be useful. It can be a bit unpredictable with no way to differentiate between downs and ups.

  • Cheers @Skyblazer - I'll try logging the notes and see what I get, might point me in the right direction and eliminate those 'grace notes' 🤣 that keep showing...

    With the played array thing, that was the only way I could think of doing it, checking if it's just been played would probably be better but I couldn't figure it out... Thinking also that I should add a condition that if it's velocity zero, it shouldn't even be triggered...

    Some other thing that intruded in my thought process was, when looking at the API reference, the velocity of pads is accessible, based on distance from centre - to my mind this means that internally the XY position must be recorded - if this were accessible in scripts, we'd be able to have multiple XY pads?

    Just wondering if it's ok to have this particular discussion here or if the learning one would be better, or even a new one just about harps? Don't want to keep spamming the wrong thread... 😬

  • edited February 2020

    @Krupa To check the last note played, you could add these three lines, indicated with ////. (And define the new LastPlayedNote variable in the OnLoad.) You'll need to use Round() on the value of notenum for this to work properly, and I would do that earlier, when notenum is first found. For knob values that translate to integers, you can use RoundDown, so that the knob positions are of equal width. SendMIDINoteOn will automatically round a value with a decimal, but if you're checking to see if two values are equal using the <> then Mozaic won't round them.

    if played[notenum]= 0
        if (notenum + transpose) <> LastPlayedNote  ////
        SendMIDINoteOn 0, notenum + transpose, velocity
        SendMIDINoteOff 0, notenum + transpose, 0, 600
        LastPlayedNote = notenum + transpose ////
        endif ////
        played[notenum]= 5
    

    Multiple XY pads sounds fun, but unlikely. :smile: But it's possible to make a multi-window, multi-script interface by having them send AU parameters or SysEx or MIDI to each other. I plan for my XY automation record/draw/edit to use the slider+XY interface to display+draw points, and the 16 buttons+4 knobs on the bottom for playhead controls etc.

    I think the thread you're referencing is for @McD's tutorial series, but I could be wrong. If there are enough people asking questions at some point, it could be good to have a dedicated topic for Mozaic programming questions.

  • @Skyblazer thanks for that, I'd gotten a bit of that into the latest version but it's very useful to have some of your knowledge 👍

    Still really stuck on the scales stuff to be honest, have neatened up the whole thing, moved some sliders about and got decent logs going - uploaded to PatchStorage. I'll probably have another go later tonight, been looking at all the scale scripts I can find for clues 😁

  • @Skyblazer said:

    I think the thread you're referencing is for @McD's tutorial series, but I could be wrong. If there are enough people asking questions at some point, it could be good to have a dedicated topic for Mozaic programming questions.

    We (general we) probably ought to revive @McD's tutorial thread and use it for examining Mozaic functionality in a much more rudimentary way than simply sharing examples of script.

    I for one, could benefit from an overview of the procedural rules of how Mozaic executes code. And more detailed descriptions to help understand events, functions, arrays, variables, knobs, and the proper way to write math equations into event parameters.

    i.e.. Can I modify the same variable in a linear way on several different lines within the same event block... Does Mozaic read and execute lines in an event block from top to bottom?

    Can I use two or more instances of the same event in the same script, and if I do how does Mozaic handle execution of multiple instances of the same event?

    It's the non-linear concept of code execution that keeps me confused, especially when I read examples of other peoples' code and see what looks to me like instructions written in a linear fashion.

    Does this mean that some aspect of Mozaic behave linearly, and others do not?

    Amongst other things I struggle to wrap my head around...

  • McDMcD
    edited February 2020

    @horsetrainer said:
    Does this mean that some aspect of Mozaic behave linearly, and others do not?

    Amongst other things I struggle to wrap my head around...

    I'll take a swing at the ball. Someone might fix any corner cases I miss.

    Generally, Mozaic only responds to 3 event types:

    1. MIDI input.
    2. PPQN DAW metronome-based events
    3. Internal Mozaic Timers

    A Mozaic script just sits and waits for these events and executes "linear lines of code" in a block bookcased by "@Name" and "@End" statements. Each of these Blocks is a FUNCTION. Some FUNCTIONS come with the product and some we design with a Custom Name and execute with a "Call @MyShit" statement.

    Where the magic comes from is a master list of MIDI events to be sent out by the Mozaic Master Controller that @Brambos wrote in the essential interpreter/execution engine.

    It maintains a timeline list of events to execute according to an internal master clock.

    So, you write an echo block and Bram's engine adds multiple output events at the right time points to send out each echo with Channel, Note, Velocity or CC details for each point in future time and future time can be a just a few internal clock ticks. Do NOT confuse this Mozaic internal clock with the DAW's clock or even some system clock.
    It's the core of Bram's excution engine which does a few things in a very, very fast loop:

    1. Adds new events to the master list as requested by the users code.
    2. Looks to see if it's time to send out any events on the master list.

    This internal list is executed internally. But there are no commands to ask questions about this list and do an extra editing or moving the clock back 3 seconds or any processing ideas we might have.

    You may only alter the future but never anything that came before now. Once written in the master list it will happen and Bram protects the app to insure that "social contract" with us is never broken. We can generate more events on that list than most targets can accept and process... we can bury a synth with MIDI events and it might appear that Mozaic is buggy but I really doubt it's failing to just output the events requested in the script commands. We wrote a bad "idea" for the target. It's a feature... use this power wisely and debug unintended consequences. Debugging is a real bitch by the way. It's often better to roll back to something that worked and try another idea to be added.

    I hope that helps.

    Where the human mind fails us here is predicting what hundred of overlapping event request will do.

    We write apps that forget to stop notes or play the wrong notes according to our expectations. It will do whatever we ask on this FUNCTION blocks.

    Does that help? or does it need to be cut into smaller pieces?

  • wimwim
    edited February 2020

    @horsetrainer said:
    i.e.. Can I modify the same variable in a linear way on several different lines within the same event block... Does Mozaic read and execute lines in an event block from top to bottom?

    Yes.

    Can I use two or more instances of the same event in the same script, and if I do how does Mozaic handle execution of multiple instances of the same event?

    No, you can’t. [edit - as @_ki mentions below, only the topmost one will execute in the case of duplicate names.]

    However, you can call the same event more than once. You use variables to get the different results from the event that you need each time you call it.

    It's the non-linear concept of code execution that keeps me confused, especially when I read examples of other peoples' code and see what looks to me like instructions written in a linear fashion.

    Does this mean that some aspect of Mozaic behave linearly, and others do not?

    Within an event things are linear. However, more than one event can be doing things at a time. (Not technically, down deep, but conceptually.)

    I can be making dinner following a recipe ... a sequence of events. I can be having a glass of wine while I cook. I may be thinking about conversation I had earlier in the day. I can be listening to a song, answering a question from the wife, checking a text message ... all pretty much at at the same time. Those are examples of separate linear processes. Each can continue their linear process because my brain keep tracks of what I’m doing and returns to each task as capacity allows.

    Events are like that. They start with a trigger and execute top to bottom within themselves until their end. But if a trigger such as an incoming MIDI note or a timer variable reaching a certain value happens during this execution, the “brain” also allocates thinking and acting resources to that other task. It doesn’t technically do more than one thing at the same time, but since its brain is fast, and it is able to keep track of where other events are in their execution, it can juggle those tasks well enough that for all intents and purposes, they’re all running simultaneously (until they aren’t because something gets overloaded ... which is rare in my experience.)

    @_ki did an excellent job some pages back at explaining how Mozaic works, event execution and priority, etc. If you look back to when you were first starting to work with Mozaic and had similar questions, I’m sure you’ll find it.

    It would be difficult to write something generalized, such as you’re saying would be helpful. IMO it’s better just to ask specific questions as you have been doing until it starts to click.

  • @horsetrainer Everything is executed linear, at each timeframe there is only one of the Mozaic events fired and the next event will be fired when the current returned. There are no interrupts in Mozaic, no event handler will be called while an event function is handled. But since everything happens so fast, it seems that that things are done in parallel.

    If there are two or more events having the same name, only the top-most event-functions is called.

  • @McD : you might want to add a link to your tutorial thread in the Mozaic wiki article

  • Thanks @McD @wim @_ki

    Those explanations help resolve one of the main things I've been confused about.

    In my mind, what you've said translates to this....

    Mozaic has two main parts. A hidden event handling engine running in the background, that linearly handles events fed into it by a code interpreter that reads code programed by the user.

    The function of Mozaic is somewhat analogous to an analog tape delay....

    An old analog tape delay transports magnetic tape first across a record head, and next across a play head. If I plug my synth audio output into the tape delay and play a bunch of notes, those sounds will be recorded onto the moving tape by the record head. Those recorded notes exist on precise physical locations on the moving tape relative to time they were recorded.

    When those recorded notes on the tape reach the play head of the tape delay. They are converted back into sounds that play in the same timing order that they were recorded.

    The output engine in Mozaic is similar to the play head of the tape delay.

    I think this analogy helps explains how this Mozaic SendMidiThru function works.

    @OnMidiInput
       SendMIDIThru
    @End
    

    Using the tape delay analogy.... The above event block tells the Mozaic "play head" to record any Midi input it receives (such as Midi Notes), onto the moving recording tape (The Backend Mozaic Buffer).

    The tape (buffer) is then read by the play head (The Mozaic output engine), and sends those midi events back out in the exact same order that they were received.

    For me this solves my confusion over how the one "SendMIDIThru" command could handle multiple rapid Midi events under the assumption that Mozaic operated in a strictly non-linear fashion.

    The front end of Mozaic is essentially non-linear, but the "output engine" running on the backend of the Mozaic program is a linear event processor.

    This...

    @OnMidiInput
       SendMIDIThru
    @End
    

    ....Is analogous to a tape delay.

    But the tape is moving so fast in Mozaic, that there is no perceptible delay.

    Thanks guys, now I have an answer to one of my biggest barriers in understanding Mozaic. :)

  • wimwim
    edited February 2020

    @horsetrainer said:
    Thanks guys, now I have an answer to one of my biggest barriers in understanding Mozaic. :)

    I think you need to expand that just a little. There is a guy sitting in front of a bank of tape machines. Those are the events. He has an earpiece through which a bunch of people are telling him which tape machines to punch in. He triggers those each time someone tells him to. He doesn’t care what #1 is done playing when he hits play on #17, he just does it. The other people sending instructions don’t care what the others are telling him either or what the other tape machines are working on, they just tell him what to do.

    OK, hopefully you’re back to total confusion. Whew. That was close.

  • @wim said:

    @horsetrainer said:
    Thanks guys, now I have an answer to one of my biggest barriers in understanding Mozaic. :)

    I think you need to expand that just a little. There is a guy sitting in front of a bank of tape machines. Those are the events. He has an earpiece through which a bunch of people are telling him which tape machines to punch in. He triggers those each time someone tells him to. He doesn’t care what #1 is done playing when he hits play on #17, he just does it. The other people sending instructions don’t care what the others are telling him either or what the other tape machines are working on, they just tell him what to do.

    OK, hopefully you’re back to total confusion. Whew. That was close.

    Yup...

    Might you (or anyone) please try to explain that concept using a minimum sample of functional Mozaic code as an example.

    And annotate the code example to explain how the Mozaic "Backend Engine" is handling events analogous to a "bank of tape machines"?

    :)

  • wimwim
    edited February 2020

    OK, I’ll bite. The script below doesn’t process midi notes, but does demonstrate trigger-based events. A MIDI note or message is just another trigger. Hopefully you get the idea.

    @Description
    Demonstrate how events independently react to triggers.
    
    Mozaic is listening for four kinds of triggers in this example:
    
    1. The program has loaded.
    2. The SHIFT button has been pressed.
    3. The number of of milliseconds we set for the timer interval has passed.
    4. A pad is hit.
    5. A knob is turned.
    
    Mozaic is listenting for these triggers independently as soon as it starts running. Whenever it detects a trigger has happened, it schedules time to execute the associated event code top to bottom, and does it. It all happens so fast that to us it's as if it's all happening independently.
    
    "Mr. Mozaic" is our tape operator. The tape machines are the events. The commands in the events are what is on the tapes. Each time a trigger noted above happens it is like someone nagging Mr. Mozaic to trigger a tape machine. 
    
    Press SHIFT to turn the timer on and off otherwise @OnTimer is never executed.
    @End
    
    @OnLoad
      // Think of this as tape machine #0. It's special beause Mr. Mozaic only
      // runs it once, before any of the others. Someone tells Mr. Mozaic to run it
      // when the script loads.
    
      // @OnLoad is where you set up initial variable values.
    
      // This is how often in milliseconds we want the @OnTimer event to fire.
      // The @OnTimer tape machine automatically loops each TimerInterval.
      SetTimerInterval 1000 //One Second
    
      //We'll use the SHIFT button to start and stop the timer. Start with it off.
      //isRunning will be the variable that we use to track and control the timer state.
      isRunning = FALSE
    
      //Start with counter at zero. This is just a variable to tell us how many timer events
      //have happened.
      counter = 0
    
      LabelKnobs {Press SHIFT to Start and Stop the Timer!!}
    @End
    
    @OnShiftDown
      // When SHIFT is pressed someone tells Mr. Mozaic to press a start or stop on 
      // the tape machine labeled "@OnTimer". See @OnTimer for notes on how that machine works.
    
      // If the timer is running, stop it, if not, start it.
      // Internally will count how long it's been running at high precision. But it won't
      // trigger @OnTimer until it reaches a multiple of the TimerInterval we set earlier.
    
      if isRunning = FALSE
        StartTimer
        Log {Timer was started by pressing SHIFT.}
      elseif isRunning = TRUE
        StopTimer
        Log {Timer was stopped by pressing SHIFT.}
      endif
    
      // Change isRunning to track the change we made above. Mr. Mozaic writes this
      // down so he remembers which button to push.
    
      isRunning = NOT isRunning
    @End
    
    @OnTimer
      // The @OnTimer tape machine automatically triggers every "TimerInterval" milliseconds.
      // Mr. Mozaic doesn't have to trigger each loop, only switch the machine between on and off
      // if someone hits the SHIFT button.
    
      // The timer is running super-fast counting off milliseconds, but we've told it with the
      // SetTimerInterval function to only triger this event every one second.
    
      // First we increase the counter variable to reflect the number of times the event has
      // been called. (Mr. Mozaic doesn't do this, it's a function of the tape machine.)
      Inc counter
    
      // And this is how we show that this was done.
      Log counter, { seconds have elapsed.}
    @End
    
    @OnPadDown
      // When someone in the control room hits a pad it sends a message to Mr. Mozaic to
      // play the @OnPadDown tape. This machine rewinds at the end, but doesn't play again
      // until Mr. Mozaic tells it to.
    
      // No matter what else you're doing, tell me when someone hits a pad.
      Log {Pad }, LastPad, { was pressed.}
    @End
    
    @OnKnobChange
      // When someone turns a knob, Mr. Mozaic not only gets instructed to play the tape,
      // but also how loud to play it.
    
      // When someone moves a knob log it's value
      Log {Knob }, LastKnob, { is at }, (GetKnobValue LastKnob) 
    @End  
    
  • Many thanks @wim ,
    Your example was extremely good at helping me understand Mozaic functionality better!

    It also made me think of an idea for a script that I think would be a very educational "Teaching Script".

    How would you write a script that does the following......

    Using three PADS in "layout 0".

    One PAD is labeled: "RECORD"
    The second PAD is labeled: "ERASE"
    The Third PAD is Labeled: "TRIGGER"

    When the user press/releases the "RECORD" pad.
    It arms the script for recording four individual notes.
    The user can then press any four sequential notes on the keyboard, and the script will remember those four notes in the order the notes were played.

    Next, the user can tap the "TRIGGER" pad at any rhythm they choose, and every single tap of the PAD will cause each of the four recorded notes to play individually, "one note at a time", "in the same order that they were recorded in". (They could loop or not, whatever is easiest)

    Lastly,
    Pressing the "ERASE" PAD, deletes any recorded notes, and readies the script for entering four new notes by again tapping the "RECORD" PAD.
    .........

    I'm also going to make a script request for a full functional version of the above principle in the script request thread. Because I really like the idea of being able to pre-enter a series of notes. Then have the ability to play them back in any rhythm you can think of by simply tapping a single pad. :)

    If it could be made to also record and play chords... better yet!

  • wimwim
    edited February 2020

    That’s pretty easy. Chords would be a little bit more tricky as you’d have to choose a time threshold for detecting a chord vs. the next note or chordnote. And storing the notes for playback is marginally more complicated because you don’t in advance how many notes to store. But still, pretty simple.

  • @wim said:
    That’s pretty easy. Chords would be a little bit more tricky as you’d have to choose a time threshold for detecting a chord vs. the next note or chordnote. And storing the notes for playback is marginally more complicated because you don’t in advance how many notes to store. But still, pretty simple.

    Cool!

    I think the simple version script should cover some of the elements of Mozaic scripting that I would really like to learn.
    e.g.. Using variables to store notes, then recalling the notes back out of the variables.

    A fully functional (useful) version of the script. Could have a knob to adjust the number of individual notes you want the script to be able to record. (or leave that number open to the number of keys the user plays?)

    Can the TRIGGER PAD be used to hold each note for as long as the Pad is held down (like a keyboard key).?

    I think such a script would be really cool for quickly composing fast played complex bass lines, and entering them onto a track by "playing" them with the single PAD.

    It should also be useful for quickly developing melodies.

    The ERASE pad lets you clear the memory and experiment with lots of ideas in short time. I think this should be a very useful compositional tool.

    :)

  • McDMcD
    edited February 2020

    @horsetrainer said:
    In my mind, what you've said translates to this....

    Mozaic has two main parts. A hidden event handling engine running in the background, that linearly handles events fed into it by a code interpreter that reads code programed by the user.

    Close but not quite accurate. There's the Script which is fed events from a single lane MIDI road.

    The script triggers FUNCTIONS based upon the MIDI event type:

    • Notes
    • CC's
    • MIDI Clock
    • etc. ( added this incase I forget some other MIDI type... like SysEx)

    That Mozaic script can store information in variables, like:

    • save note details (memorize) in a list (useful for making loopers, playing chords, detecting incoming chords)
    • save CC values to use as parameters (like Channel, Volume, LFO settings).

    "memorize" is a nice analogy for the timeline in the core engine. It's a long running memo/list of events to sent out with timestamps on them: a "to do later" list.

    The script can also forward MIDI outputs the the BACKEND runtime wizard that accepts commands and manages the future timeline.

    I'll use the Echo example again:

    1. Note comes in on the MIDI road
    2. Mozaic passes the NOTE ON details to the OnMidi code function
    3. The user script decides everything that follows and the OnMIDI commands all run in 0.0000001th of a second

    Almost all details other than these are up to the script writer. Mozaic can accept slow MIDI streams from the MIDI road in and request thousands of MIDI events be sent in the future. What is sent and at what time is all coded in the FUNCTIONS commends. One event in and 1 to 100,000 events out.

    All the other questions have to do with using Variables and Commands to create interesting MIDI FX solutions.

    The things that can't be done usually have to do with someone asking for an event out in response to
    something changing in the future. That won't fit on the 3-step loop of execution. Programmers call this type of Loop a REPL (read-eval-print loop)

    1. read from the MIDI highway in
    2. evaluate (that backend is really evaluating the commands in our functions)
    3. print (either send out an immediate event or make a notation on the timeline list to do it later)
    4. loop (go back to #1 for a new event) "No! Not the dreaded Go To Statement"

    My description does mention an explicit Go To but it does help understand the real time flow of
    the engine.

    Does that help any further...
    Studying any single script misses something essential... you can build some amazingly complex MIDI Functions and each one is a unique script with it's own internal logic.

  • You’re pretty good at articulating what you want, so maybe you should noodle on it until what you want it to do fully gels, then float it over on the script request thread. Most likely someone will pick it up.

Sign In or Register to comment.