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!

13637394142102

Comments

  • If it was discussed here, I missed it. Can GLOBALs be saved between sessions?

  • @espiegel123 said:
    @brambos : I have started writing some things in MidiDesigner Pro to talk to my Boss Katana amp -- which pretty much exclusively speaks sysex and not MIDI CC. I would much rather be doing this is Mozaic. It would be awesome if you added the ability to send SysEx or raw midi bytes -- unless it is there and I have missed it.

    p.sl I don't (at this stage) need to listen to incoming sysex -- but that would probably be handy if it could

    Man-guessing here - but isn’t it possible to use the Mozaic SendMidiOut function?
    It sends three bytes - but what if you just do more calls to it if you have a longer SysEx message?

    SendMIDIOut
    SendMIDIOut <byte1>, <byte2>, <bute3> [,<delay>]
    Description: Sends out a free-form MIDI message defined by the contents of <byte1>, <byte2> and <byte3>. Some MIDI messages require fewer than three bytes, but Mozaic checks this for you and sends out the correct number of bytes accordingly.
    Parameters and output:
    <byte1>
    MIDI event message
    <byte2>
    <byte3>
    <delay>
    Example:
    first data byte, contents depend on the event message second data byte, contents depend on the event message
    Optional delay (in milliseconds) before the MIDI message is sent out. If left out or set to 0, the message is sent out immediately.
    Mozaic 1.0.3
    !68 of !83
    @OnMIDIInput
      SendMIDIOut MIDIByte1, MIDIByte2, MIDIByte3 // forward all incoming MIDI
    @End
    
  • edited August 2019

    I put a new script up on parchstorage called Chaos LFO.

    This script utilizes Lorenz and Rössler differential equations—which are known for having chaotic solutions under certain starting conditions—to generate three unpredictable cyclic MIDI CC LFOs called X, Y, and Z. Use the middle three knobs on the bottom row to select which CC# are used for X, Y, and Z. In order to make dialing in CCs easier, the range of the CC knobs may be changed using the CC RANGE knob on the far right.

    The upper left pad selects between Lorenz and Rössler mode. Use the SPEED knob to control how fast the LFO goes. Three SPEED RANGES are available, selected by the upper right pad: GLACIAL, SLOW, and FAST. The output of the LFO may be passed through a sample and hold. The lower right pad selects between SAMPLE & HOLD or CLOCKED MODE. Use the RATE/CLOCK knob on the lower left to adjust the rate at which the LFO is sampled. In CLOCKED MODE the LFO is sampled at divisions of the host tempo. To use this mode the host’s transport must be running. A warning will appear above the pads if the transport is not running.

    The σ, ρ, β, and a, b, c knobs control constants in the Lorenz and Rössler equations. You may want to experiment with these, although not all combinations of values create chaotic oscillations. Use the RESET pad to reset to default values. The DISPLAY knob selects between several modes of displaying the LFOs on the XY PAD, either individually or in combination.

  • edited August 2019

    @Bryan said:
    I put a new script up on parchstorage called Chaos LFO.

    This script utilizes Lorenz and Rössler differential equations—which are known for having chaotic solutions under certain starting conditions—to generate three unpredictable cyclic MIDI CC LFOs called X, Y, and Z. Use the middle three knobs on the bottom row to select which CC# are used for X, Y, and Z. In order to make dialing in CCs easier, the range of the CC knobs may be changed using the CC RANGE knob on the far right.

    The upper left pad selects between Lorenz and Rössler mode. Use the SPEED knob to control how fast the LFO goes. Three SPEED RANGES are available, selected by the upper right pad: GLACIAL, SLOW, and FAST. The output of the LFO may be passed through a sample and hold. The lower right pad selects between SAMPLE & HOLD or CLOCKED MODE. Use the RATE/CLOCK knob on the lower left to adjust the rate at which the LFO is sampled. In CLOCKED MODE the LFO is sampled at divisions of the host tempo. To use this mode the host’s transport must be running. A warning will appear above the pads if the transport is not running.

    The σ, ρ, β, and a, b, c knobs control constants in the Lorenz and Rössler equations. You may want to experiment with these, although not all combinations of values create chaotic oscillations. Use the RESET pad to reset to default values. The DISPLAY knob selects between several modes of displaying the LFOs on the XY PAD, either individually or in combination.

    @Bryan just tried it on Sunrizer mapping the 3 knob cc to Sunrizer LFO frequency couldn’t get it to work. As these scripts in Mozaic are getting better they are getting more complex and personally the operating descriptions are failing me ! Loving the scripts but over my pay grade to set up!

    Maybe a AUM file post or a video showing how to set up would help.

    With a AUM file I could see how the routing etc is achieved!

  • edited August 2019

    @Jumpercollins

    The easiest way to set it up in AUM is to go to the main menu (the three horizontal lines on the top right) and select MIDI CTRL (bottom right item). Then down at the bottom, find the channel you have Sunrizer on and tap that. On the next page, tap Sunrizer Parameters. Here you can find all the parameters you can control in Sunrizer. For example, if you want to control the LFO 1 frequency, scroll down until you find it, then tap on it. A little window will appear at the bottom and here you must select the midi channel (which will initially say “OFF”; set it to “CH 1”) and the CC value (set it to “CC13” or whatever CC you have set in Mozaic). Finally, exit this menu and go to MIDI ROUTING (the squiggly line at the top right). Here you need to route Mozaic to MIDI Control by tapping the square that makes the arrow point from “Mozaic” to “MIDI Control”.

  • edited August 2019

    @Bryan said:
    @Jumpercollins

    The easiest way to set it up in AUM is to go to the main menu (the three horizontal lines on the top right) and select MIDI CTRL (bottom right item). Then down at the bottom, find the channel you have Sunrizer on and tap that. On the next page, tap Sunrizer Parameters. Here you can find all the parameters you can control in Sunrizer. For example, if you want to control the LFO 1 frequency, scroll down until you find it, then tap on it. A little window will appear at the bottom and here you must select the midi channel (which will initially say “OFF”; set it to “CH 1”) and the CC value (set it to “CC13” or whatever CC you have set in Mozaic). Finally, exit this menu and go to MIDI ROUTING (the squiggly line at the top right). Here you need to route Mozaic to MIDI Control by tapping the square that makes the arrow point from “Mozaic” to “MIDI Control”.

    @Bryan cheers for the detailed setup instructions I managed to get something going in AUM using it prior to reading this so will try again now I know more.

    Here’s my first attempt with Chaos

    http://preset.audiob.us/#m3ssk4Be3nkhtEx

  • Back home from vacation and now working on the next Mozaic update...

    • Added Arpticles preset
    • Multi-line pad labels are now possible
    • Case-insensitive preset ordering also done
    • Fixed all reported bugs

    More to come!

  • @brambos said:
    Back home from vacation and now working on the next Mozaic update...

    • Added Arpticles preset
    • Multi-line pad labels are now possible
    • Case-insensitive preset ordering also done
    • Fixed all reported bugs

    More to come!

    @brambos Hope you had a great hols, glad your back and hard at work for us all again.

    The Mozaic patchstorage content has gone into overdrive whilst you been away so much goodness coming out of Mozaic now.

  • @Peblin said:

    @espiegel123 said:
    @brambos : I have started writing some things in MidiDesigner Pro to talk to my Boss Katana amp -- which pretty much exclusively speaks sysex and not MIDI CC. I would much rather be doing this is Mozaic. It would be awesome if you added the ability to send SysEx or raw midi bytes -- unless it is there and I have missed it.

    p.sl I don't (at this stage) need to listen to incoming sysex -- but that would probably be handy if it could

    Man-guessing here - but isn’t it possible to use the Mozaic SendMidiOut function?
    It sends three bytes - but what if you just do more calls to it if you have a longer SysEx message?

    SendMIDIOut
    SendMIDIOut <byte1>, <byte2>, <bute3> [,<delay>]
    Description: Sends out a free-form MIDI message defined by the contents of <byte1>, <byte2> and <byte3>. Some MIDI messages require fewer than three bytes, but Mozaic checks this for you and sends out the correct number of bytes accordingly.
    Parameters and output:
    <byte1>
    MIDI event message
    <byte2>
    <byte3>
    <delay>
    Example:
    first data byte, contents depend on the event message second data byte, contents depend on the event message
    Optional delay (in milliseconds) before the MIDI message is sent out. If left out or set to 0, the message is sent out immediately.
    Mozaic 1.0.3
    !68 of !83
    @OnMIDIInput
      SendMIDIOut MIDIByte1, MIDIByte2, MIDIByte3 // forward all incoming MIDI
    @End
    

    Thanks. I'll give it a try. I was thrown off by a note in the docs that Mozaic won't send sysex. Ideally, a command to send more bytes would be good. Maybe, something that takes an array with the bytes to send and a count parameter.

    Thinking out loud: if sendmidiout allows sysex, I could use a global array and write a handler that sends the array's bytes out 3 at a time.

  • edited August 2019

    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

  • @brambos said:
    Working on a new preset for the next Mozaic update: Arpticles.

    It's a hybrid particle generator/arpeggiator. Obviously also a nice starting point for tinkering and making more advanced scripts if you don't want to start from scratch or just want to learn some techniques for arpeggiator-type scripts.

    Very nice! Looking forward to this one...

  • @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

  • @motmeister said:
    If it was discussed here, I missed it. Can GLOBALs be saved between sessions?

    Was it a stupid question? This post is now 39 pages long. I looked but did not see the subject of saving GLOBALs discussed.

  • @motmeister said:

    @motmeister said:
    If it was discussed here, I missed it. Can GLOBALs be saved between sessions?

    Was it a stupid question? This post is now 39 pages long. I looked but did not see the subject of saving GLOBALs discussed.

    Look in the docs. Your question is answered there.

  • @espiegel123 said:

    @motmeister said:

    @motmeister said:
    If it was discussed here, I missed it. Can GLOBALs be saved between sessions?

    Was it a stupid question? This post is now 39 pages long. I looked but did not see the subject of saving GLOBALs discussed.

    Look in the docs. Your question is answered there.

    The documentation on page 10, which appears to be the only description of GLOBALs in the manual, does not address their persistence. Thanks for your answer. I’m looking into it further.

  • @motmeister said:

    @espiegel123 said:

    @motmeister said:

    @motmeister said:
    If it was discussed here, I missed it. Can GLOBALs be saved between sessions?

    Was it a stupid question? This post is now 39 pages long. I looked but did not see the subject of saving GLOBALs discussed.

    Look in the docs. Your question is answered there.

    The documentation on page 10, which appears to be the only description of GLOBALs in the manual, does not address their persistence. Thanks for your answer. I’m looking into it further.

    They re-initialized when you exit and re-enter the host. However, if you save a session in the host, and reload it, they are preserved like any other variable. They’re just like other variables except can be referenced across running instances.

  • edited August 2019

    Globals are not persistent. They don’t belong to any one instance of the plugin so saving them would become an almost philosophical conumdrum. :)

    They are also only meant/used for communication between instances, which means their nature is typically transient.

  • @espiegel123 said:

    @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

    Getting a bit more up to speed on sysex. Roland gear uses checksums as the last byte and has series of bytes with manufacturer and model id.

    MidiDesigner has options for sysex messages which would be very helpful in They have checksum options: none, Roland, Axe FX II, Roland Two-Byte Model ID , Roland Three-Byte Model ID and Roland Four-Byte Model ID.

    It would be pretty cumbersome to have to try calculate the checksums.

  • @_ki that is so cool.

  • edited August 2019

    @espiegel123 said:

    @espiegel123 said:

    @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

    Getting a bit more up to speed on sysex. Roland gear uses checksums as the last byte and has series of bytes with manufacturer and model id.

    MidiDesigner has options for sysex messages which would be very helpful in They have checksum options: none, Roland, Axe FX II, Roland Two-Byte Model ID , Roland Three-Byte Model ID and Roland Four-Byte Model ID.

    It would be pretty cumbersome to have to try calculate the checksums.

    I can look at the checksum calculations but I feel that highly vendor-specific stuff doesn't belong in a language on a syntax level. I don't feel like reworking my language when AXE FX 3 comes out. :#

  • @brambos said:

    @espiegel123 said:

    @espiegel123 said:

    @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

    Getting a bit more up to speed on sysex. Roland gear uses checksums as the last byte and has series of bytes with manufacturer and model id.

    MidiDesigner has options for sysex messages which would be very helpful in They have checksum options: none, Roland, Axe FX II, Roland Two-Byte Model ID , Roland Three-Byte Model ID and Roland Four-Byte Model ID.

    It would be pretty cumbersome to have to try calculate the checksums.

    I can look at the checksum calculations but I feel that highly vendor-specific stuff doesn't belong in a language on a syntax level. I don't feel like reworking my language when AXE FX 3 comes out. :#

    After looking at it some more, I think having a sysex a generic checksum function would work that would take bytes in an area and return a byte. It looks like the checksum algorithm itself is generic and that the “flavor” in MD tells it how many header bytes to skip.

    I can see two approaches that you could take that would handle the overwhelming majority of use-cases.

    One would do the checksum as part of the sendMIDIsysex command. And have the parameters be something like,

    SendMIDIsysex ,,

    checkSumType 0 would be no checksum. If there are a few standard or widely used checksum . The checksum would be calculated from the messageBytes. The sent sysex would be f0 f7

    Another solution is to have a separate checksum function that takes an array of bytes. The takes responsibility for passing the correct bytes and building the sysex message. The checksum function might still have a checksumType argument if there are multiple algos people are using. My brief search makes it seem like the Roland/Boss use-case predominates.

  • @espiegel123 said:

    @brambos said:

    @espiegel123 said:

    @espiegel123 said:

    @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

    Getting a bit more up to speed on sysex. Roland gear uses checksums as the last byte and has series of bytes with manufacturer and model id.

    MidiDesigner has options for sysex messages which would be very helpful in They have checksum options: none, Roland, Axe FX II, Roland Two-Byte Model ID , Roland Three-Byte Model ID and Roland Four-Byte Model ID.

    It would be pretty cumbersome to have to try calculate the checksums.

    I can look at the checksum calculations but I feel that highly vendor-specific stuff doesn't belong in a language on a syntax level. I don't feel like reworking my language when AXE FX 3 comes out. :#

    After looking at it some more, I think having a sysex a generic checksum function would work that would take bytes in an area and return a byte. It looks like the checksum algorithm itself is generic and that the “flavor” in MD tells it how many header bytes to skip.

    I can see two approaches that you could take that would handle the overwhelming majority of use-cases.

    One would do the checksum as part of the sendMIDIsysex command. And have the parameters be something like,

    SendMIDIsysex ,,

    checkSumType 0 would be no checksum. If there are a few standard or widely used checksum . The checksum would be calculated from the messageBytes. The sent sysex would be f0 f7

    Another solution is to have a separate checksum function that takes an array of bytes. The takes responsibility for passing the correct bytes and building the sysex message. The checksum function might still have a checksumType argument if there are multiple algos people are using. My brief search makes it seem like the Roland/Boss use-case predominates.

    Yeah.. I reckon Roland is one of the few who use checksums (and have been using the same algorithm since the Juno 106), so adding a Roland checksum feature probably isn't an issue. But adding the device/model/manufacturer bytes should really be up to the user imo.

  • Wow! That's a really awesome and incredibly powerful script. :o

  • Hi

    I just released the first version of Orchestra, which I'm calling a MIDI "meta sequencer". I started it's own thread for the script, which you can find here:

    https://forum.audiob.us/discussion/34156/orchestra-scene-based-metasequencer-for-mozaic/p1?new=1

    The goal is to be able to build a modular-sequencer based "session mode" to develop live sets or song structure.

    Script here:
    https://patchstorage.com/orchestra/

    Tiny demo, although it won't be clear what's happening, Orchestra is scheduling the program changes of both the x0xb0x and the Rozeta bassline sequencer (via AUM MIDI Control mapping to load presets)

  • @brambos said:

    @espiegel123 said:

    @brambos said:

    @espiegel123 said:

    @espiegel123 said:

    @brambos said:
    What sort of Sysex are you trying to send?

    Asking for a friend. ;)

    Seriously though, I'm worried that if I enable Sysex, people expect to be able to send and receive huge data dumps or even sample-data. Which is something I do not want to (and probably can't even practically) support - and I don't like adding things that backfire in my face. Better to be clear and leave things out altogether in that case.

    If we can limit Sysex data to whatever fits inside a Mozaic array (i.e. up to 1000 elements) it may be a lot more realistic for me to implement properly without having to change fundamental things (and reuse existing data structures).

    I am still very much in the noob stage of figuring out the Boss Katana stuff, but it looks like most of the messages that I need to send involve small amounts of data per sysex packet (on the other of 16 bytes or so) of the sort that I need to send. There might be some messages that are larger but nothing that would require more than 1000 elements.

    Getting a bit more up to speed on sysex. Roland gear uses checksums as the last byte and has series of bytes with manufacturer and model id.

    MidiDesigner has options for sysex messages which would be very helpful in They have checksum options: none, Roland, Axe FX II, Roland Two-Byte Model ID , Roland Three-Byte Model ID and Roland Four-Byte Model ID.

    It would be pretty cumbersome to have to try calculate the checksums.

    I can look at the checksum calculations but I feel that highly vendor-specific stuff doesn't belong in a language on a syntax level. I don't feel like reworking my language when AXE FX 3 comes out. :#

    After looking at it some more, I think having a sysex a generic checksum function would work that would take bytes in an area and return a byte. It looks like the checksum algorithm itself is generic and that the “flavor” in MD tells it how many header bytes to skip.

    I can see two approaches that you could take that would handle the overwhelming majority of use-cases.

    One would do the checksum as part of the sendMIDIsysex command. And have the parameters be something like,

    SendMIDIsysex ,,

    checkSumType 0 would be no checksum. If there are a few standard or widely used checksum . The checksum would be calculated from the messageBytes. The sent sysex would be f0 f7

    Another solution is to have a separate checksum function that takes an array of bytes. The takes responsibility for passing the correct bytes and building the sysex message. The checksum function might still have a checksumType argument if there are multiple algos people are using. My brief search makes it seem like the Roland/Boss use-case predominates.

    Yeah.. I reckon Roland is one of the few who use checksums (and have been using the same algorithm since the Juno 106), so adding a Roland checksum feature probably isn't an issue. But adding the device/model/manufacturer bytes should really be up to the user imo.

    Maybe I wasn't clear, I wasn't suggesting that Mozaic have a database of the headerbytes just that the sendsysex have a parameter in which the user stashes that stuff if sysex also has a checksum. The user fills that in with the bytes that get ignored by the checksum. Maybe it would be the last parameter so that it could be an optional param.

  • edited August 2019

    Yet another script for you all, now up on patchstorage.com.

    This script contains two independent MIDI CC Sample and Hold devices. Each S&H is routed to a simple CC processor with GAIN attenuverter, OFFSET, and SLEW control. Select the CC to be sampled with the knobs on the far left. The range of the knob is set by the upper left side pads. The second knob from the left has multiple functions depending on the mode set by the right pad. There are four modes: CLOCK SYNC, FREE RUNNING, NOTE TRIG S&H and NOTE TRIG T&H. CLOCK SYNC is syncronized to the host tempo and will sample and hold the incoming CC value at a rate set by the CLOCK knob. The host transport must be playing for this mode to function (a warning will appear if the host is not running). FREE RUNNING uses an internal clock not syncronized to the host. NOTE TRIG S&H and NOTE TRIG T&H will trigger when an incoming MIDI Note On message is received. The difference is that NOTE TRIG T&H (Track & Hold) only holds the CC value while MIDI Note On is held; otherwise it tracks the input (i.e., the CC passes through uneffected). The SKIP knob sets how many Note On messages must occur before a CC value is held.

    The XY PAD displays the output of one of the S&H devices. The lower left pad determines which device's output is displayed. Press and hold SHIFT to show the values of the knobs.

  • Can’t keep up with all this Script goodness haven’t got enough hours in the day to learn how to use them all lol🙄.

  • Yes, some very clever and creative people have taken Mozaic, and are running with it!

    This is beyond anything I had expected. :)

  • @Jumpercollins said:
    Can’t keep up with all this Script goodness haven’t got enough hours in the day to learn how to use them all lol🙄.

    There are some major Moziac superstars here. I wish I had time to create my own stuff but enjoying everything (or trying to) what folks are putting out.

Sign In or Register to comment.