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

wim

@Artefact2001 said:
Can someone give me some guidance on importing scripts from Dropbox? I’m using ‘open in’, which opens up Mozaic but doesn’t copy the code, sorry if this is super obvious!

It doesn’t open the code as the current project, but if you go to the load button you should see the project available to load.

wim

@McD said:

I looked at one of @wim's scripts and he adds a delay for every echo and has some logic to
stop a note if the delay is shorter than the first echo and extra logic to stop the last echo.
But it's a careful implementation of option #1.

His delay value is tied to some math around a PPQN knob and a Multiplier Knob so his echoes are based upon fractions of the Host's BPM settings. Thanks for asking the question.
It made me learn something new and I found code that works.

Rather than try to have each echo note be the same length as the original note, I decided to ensure that there were no overlapping note ons. This results in truncation of notes if they’re longer than the period between echos, but I felt that was better for a rhythmic delay.

For a mono synth, sending two note ons for the same note without a note off between them off will often not sound the second. For any synth it could be unpredictable. Also, I wanted to be as sure as possible there were never stuck notes. So, I decided that there would always be a note off before the next echo, and of course one after the last. With this approach, I didn’t need to keep track of note length. It also resulted in a more rhythmic sounding echo, which is what I was going for.

But it did get me to thinking “how would I do this if I needed to preserve the note length somehow.?”

wim

@brambos said:

@lovadamusic said:
Since the spirit of the app is to make things accessible to a beginner, simplicity would seem to be the better choice.

I'm really enjoying learning and playing around with MOZAIC. I have some scripting experience from way back, so it's making good sense to me, but with the very nicely written Programming Manual, anyone wanting to learn should be able to get into it. Once learned, I'd expect scripters like me would want to see user functions where we can pass variables and get back a result. Buttons that light up for switching things on and off might be nice, as would drop down lists, labeled pads, and... so much for simplicity.

Yeah.. I'm vigilant for scope-creep. But adding things that are just really useful will make it into the language. Such as user-defined functions and some more array manipulation functions.

Array initializers and array copying are now working...

source = [1,2,3,4,5,6]
CopyArray source, destination, 6 // copy the first 6 cells of array source into array destination

I like that. It’s going to reduce the number of lines of code significantly.

What happens if I want to add some more cells to source? Back to for loops, or do you have something clever cooking?

McD

@brambos said:

@Samu said:
Hmm, I’ll grab Mozaic as soon as I get me some more gift-cards...

How does one grab the ‘note lenght’(ie. how long the note was held to avoid stuck notes?).
This could be useful for creating a realistic midi-echo with feedback options.

As expected there are many different ways to go about. I would use a counter to count the number of metronome pulses between note on/off. Something like this:

@OnLoad
  counter = 0
  FillArray notestarts, 0
  SetMetroPPQN 48 // if it's good enough for Cubasis...! :-)
@End

@OnMetroPulse
  Inc counter
@End

@OnMidiNoteOn
  notestarts[MIDINote] = counter
@End

@OnMidiNoteOff
  length = counter - notestarts[MIDINote]
  Log {Length of Note }, MIDINote, { = }, length
@End

Thanks! Nice and on point. I suspect some folks could benefit from some annotations explaining the way these Mozaic functions are used. This opened new doors for me. Bram does all the heavy lifting to make it as easy as possible to use the host’s clock and Pulses Per Quarter Note suddenly makes practical sense for the timing puzzles. The note happened N ticks after the last quarter note. Seems simple when you see the magic (and you have some experience with functions).

AndyPlankton

@dendy said:
@StartOfDreams

would be really great, if some devs would put heads together and create universal API - easy to adopt - for saving and sharing AU patches between users. With tagging, charts, searching by name, genre, author, etc... stuff like that.

Like universal patch browser,with centralised database server for easy sharing between users, which will bring some standards into AU plugins patch management wild west...

"PatchBus" .. maybe side-project for @Michael :-))

@EndOfDreams

Maybe something for @j_liljedahl and AudioShare ?

brambos

@McD said:

@brambos said:

@Samu said:
Hmm, I’ll grab Mozaic as soon as I get me some more gift-cards...

How does one grab the ‘note lenght’(ie. how long the note was held to avoid stuck notes?).
This could be useful for creating a realistic midi-echo with feedback options.

As expected there are many different ways to go about. I would use a counter to count the number of metronome pulses between note on/off. Something like this:

@OnLoad
  counter = 0
  FillArray notestarts, 0
  SetMetroPPQN 48 // if it's good enough for Cubasis...! :-)
@End

@OnMetroPulse
  Inc counter
@End

@OnMidiNoteOn
  notestarts[MIDINote] = counter
@End

@OnMidiNoteOff
  length = counter - notestarts[MIDINote]
  Log {Length of Note }, MIDINote, { = }, length
@End

Thanks! Nice and on point. I suspect some folks could benefit from some annotations explaining the way these Mozaic functions are used. This opened new doors for me. Bram does all the heavy lifting to make it as easy as possible to use the host’s clock and Pulses Per Quarter Note suddenly makes practical sense for the timing puzzles. The note happened N ticks after the last quarter note. Seems simple when you see the magic (and you have some experience with functions).

Yeah.. this is the sort of stuff that ends up in the "Tutorials" folder. In fact I may polish this one a little bit and add it

brambos

@wim said:

@brambos said:

@lovadamusic said:
Since the spirit of the app is to make things accessible to a beginner, simplicity would seem to be the better choice.

I'm really enjoying learning and playing around with MOZAIC. I have some scripting experience from way back, so it's making good sense to me, but with the very nicely written Programming Manual, anyone wanting to learn should be able to get into it. Once learned, I'd expect scripters like me would want to see user functions where we can pass variables and get back a result. Buttons that light up for switching things on and off might be nice, as would drop down lists, labeled pads, and... so much for simplicity.

Yeah.. I'm vigilant for scope-creep. But adding things that are just really useful will make it into the language. Such as user-defined functions and some more array manipulation functions.

Array initializers and array copying are now working...

source = [1,2,3,4,5,6]
CopyArray source, destination, 6 // copy the first 6 cells of array source into array destination

I like that. It’s going to reduce the number of lines of code significantly.

What happens if I want to add some more cells to source? Back to for loops, or do you have something clever cooking?

I think it already automatically adds the array initializer to the index you specify...

source[6] = [7,8,9,10] // add 4 numbers starting at index 6

and

CopyArray source[6], destination[6], 4

I haven't tested this yet, but it should work already in my code unless I actively block it. I'll test tonight

Billflinton

Some thoughts regarding UI customization: I’d love to have more options when it comes to layout, but I’m fully aware how big the risk of adding complexity is, especially after spending dozens of hours with KRFT some time ago. Interestingly, the main problem I had with it wasn’t that it was difficult or complicated (it isn’t) but the fact that I had to manually position all of the controls and make decisions at every step had quickly become a chore for me and took away all the fun.

Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately? I think it could still be relatively simple, but I would be able to mix and match whatever fits my needs in a given situation, eg. I could have a row of pads in the upper half and set of knobs in the bottom. And to keep it simple and backwards compatible (also still easy to learn in the beginning) the original approach could still be available. I’m a big believer in “progressive disclosure of complexity” philosophy and I think this solution would fit into this model of “easy at first, optionally more and more complex when you need it”.

wim

@Matt_Fletcher_2000 said:

@wim said:

I’ll think about your ideas. I kind of want to keep it from getting too complicated though.

Absolutely!!!

It’s pretty much perfect as it is.

[If you do a randomiser then please, please consider being able to randomise (or not) each of the four positions/pads independently. That would be a lot more useful than a global randomise of everything. That’s why I was thinking something like ‘long press of shift and then tap one of the 4 pads you want to randomise the settings of’. ]

Yes, that would be the ideal way to go and not too difficult to do. The thing is the shift button isn’t exposed as an AU parameter so it can’t be automated. Pads aren’t exposed as AU parameters either, but there’s a way around that. I was planning to add AU automation for everything, including saving the snapshots.

But, while typing this, I think I figured out how to pull it off. When I finish the new project I’m working on (or need a break from it), I’ll come back to this one.

wim

@Billflinton said:
Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately?

You beat me to it.

I was thinking of suggesting something like that too. Keeping the existing views, but adding one that divided into three or four panels, each configurable to be knobs, sliders, pads, or XY.

I’ve not been minding the current constraints, but I’m guessing it will be a thing requested over and over. Something like this might give enough configurability without over complicating things.

brambos

@wim said:

@Billflinton said:
Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately?

You beat me to it.

I was thinking of suggesting something like that too. Keeping the existing views, but adding one that divided into three or four panels, each configurable to be knobs, sliders, pads, or XY.

I’ve not been minding the current constraints, but I’m guessing it will be a thing requested over and over. Something like this might give enough configurability without over complicating things.

Yeah.. this one is on the back-burner, but certianly still burning nonetheless.

wim

@brambos said:

@wim said:

@brambos said:

@lovadamusic said:
Since the spirit of the app is to make things accessible to a beginner, simplicity would seem to be the better choice.

I'm really enjoying learning and playing around with MOZAIC. I have some scripting experience from way back, so it's making good sense to me, but with the very nicely written Programming Manual, anyone wanting to learn should be able to get into it. Once learned, I'd expect scripters like me would want to see user functions where we can pass variables and get back a result. Buttons that light up for switching things on and off might be nice, as would drop down lists, labeled pads, and... so much for simplicity.

Yeah.. I'm vigilant for scope-creep. But adding things that are just really useful will make it into the language. Such as user-defined functions and some more array manipulation functions.

Array initializers and array copying are now working...

source = [1,2,3,4,5,6]
CopyArray source, destination, 6 // copy the first 6 cells of array source into array destination

I like that. It’s going to reduce the number of lines of code significantly.

What happens if I want to add some more cells to source? Back to for loops, or do you have something clever cooking?

I think it already automatically adds the array initializer to the index you specify...

source[6] = [7,8,9,10] // add 4 numbers starting at index 6

and

CopyArray source[6], destination[6], 4

I haven't tested this yet, but it should work already in my code unless I actively block it. I'll test tonight

Perfect.

rs2000

@busker said:
Sorry if this has been answered already, but can Mozaic handle SysEx?

I don’t mean device dumps, just short messages.

I’m currently using StreamByter for this purpose, but interested in trying Mozaic as well.

From the manual:

Since most AU hosts do not allow transmission or reception of Sysex messages, these are left out of the scope of this guide (and are for now not supported by Mozaic).

Another question @brambos:
Is there any way an AU plugin could retrieve the current parameter values from another AU, like a synth, for example?
If not, what would the host have to do in order to make it possible?
The idea is to support parameter feedback to hardware controllers with illuminated pads, LEDs, flying faders, LED rings, displays and so on.

brambos

@rs2000 said:

@busker said:
Sorry if this has been answered already, but can Mozaic handle SysEx?

I don’t mean device dumps, just short messages.

I’m currently using StreamByter for this purpose, but interested in trying Mozaic as well.

From the manual:

Since most AU hosts do not allow transmission or reception of Sysex messages, these are left out of the scope of this guide (and are for now not supported by Mozaic).

I discussed this with Jonatan the other day, and at least with AUM it should now be possible (it wasn't when I was looking into sending Sysex into Phasemaker). So I can consider adding a "SendSysex" function at some point for those hosts which do support it. With the enormous caveat that it may not work in your (other) host of choice (I tend to avoid things that don't work everywhere, because those always lead to lots of support effort).

Another question @brambos:
Is there any way an AU plugin could retrieve the current parameter values from another AU, like a synth, for example?
If not, what would the host have to do in order to make it possible?
The idea is to support parameter feedback to hardware controllers with illuminated pads, LEDs, flying faders, LED rings, displays and so on.

The host has to pass it, because plugins can't talk with each other's AU parameters. I'm not currently aware of any host that lets you do that, hence MIDI CC is now typically the way to pull it off.

If a host wanted to make this possible, it would have to let the user select a source AU Parameter in a plugin and a destination AU parameter in another plugin, and make sure that the format of the source is scaled/translated into the format of the destination. Whenever the source parameter is changed the host is notified. It would then have to notify the destination plugin in turn.

AndyPlankton

@rs2000 said:

@busker said:
Sorry if this has been answered already, but can Mozaic handle SysEx?

I don’t mean device dumps, just short messages.

I’m currently using StreamByter for this purpose, but interested in trying Mozaic as well.

From the manual:

Since most AU hosts do not allow transmission or reception of Sysex messages, these are left out of the scope of this guide (and are for now not supported by Mozaic).

Another question @brambos:
Is there any way an AU plugin could retrieve the current parameter values from another AU, like a synth, for example?
If not, what would the host have to do in order to make it possible?
The idea is to support parameter feedback to hardware controllers with illuminated pads, LEDs, flying faders, LED rings, displays and so on.

I too thought about trying to do controller feedback How do you plan to get around the single device limit ? I figured it wouldn't be simple as you cannot talk to both controller and synth without very careful channel management.

wim

@brambos, is there a reason why AU parameters update knobs, but knobs don’t update their AU parameters? Can that be changed? It really needs to be bi-directional.

brambos

@wim said:
@brambos, is there a reason why AU parameters update knobs, but knobs don’t update their AU parameters? Can that be changed? It really needs to be bi-directional.

They should be bi-directional already. But I’ll check

chandroji

Hi @brambos !
I just downloaded your pdf manual. Very well written! 👍

Last time I coded little applications was 1987. Since then I never touched again a programming or script language except html, JavaScript, CSS and PHP some years ago!

I’m interesting to find a way in your script language and I think your manual and tutorials will help me! I’m curious!

Thanks a lot for for it! 😊

Poppadocrock

DevHub for GitHub by Bruno Lemos, is free today, usually 7.99. Not sure if it’s any good, but it has good reviews.

Poppadocrock

Patchstorage is a good choice.

brambos

@chandroji said:
Hi @brambos !
I just downloaded your pdf manual. Very well written! 👍

Thanks! I’ve put a lot of effort in it. I think that for this product the manual is one of the key factors for making it work. Also for myself: if I can’t explain something concisely, it’s not simple enough

ZenEagle

@brambos said:

@wim said:

@Billflinton said:
Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately?

You beat me to it.

I was thinking of suggesting something like that too. Keeping the existing views, but adding one that divided into three or four panels, each configurable to be knobs, sliders, pads, or XY.

I’ve not been minding the current constraints, but I’m guessing it will be a thing requested over and over. Something like this might give enough configurability without over complicating things.

Yeah.. this one is on the back-burner, but certianly still burning nonetheless.

Not sure if you’re planning any more UI element types, but the one I can think of that would make sense and not take up much screen real-estate, would be to have small two state (on/off) toggle switches. (either on/off buttons or sliding switches) For now I’m using the pos/neg extremes of a slider for the same.

wim

The new share button is a big help. 👍

wim

This one is nothing fancy but might be useful to someone.

MIDI CC Randomizer

Double-tap the Randomize knob or turn it to 50% or higher to randomize the values for each cc. You can also send a value of 64 or higher to the KNOB 0 AU parameter to trigger randomization. The last knob sets the outbound channel for the cc messages.

https://www.dropbox.com/s/e3ny0ui8mduanxz/MIDI CC Randomizer.mozaic?dl=0

rs2000

@Poppadocrock said:
DevHub for GitHub by Bruno Lemos, is free today, usually 7.99. Not sure if it’s any good, but it has good reviews.

Thank you, looks good!

Trueyorky

@wim said:
This one is nothing fancy but might be useful to someone.

MIDI CC Randomizer

Double-tap the Randomize knob or turn it to 50% or higher to randomize the values for each cc. You can also send a value of 64 or higher to the KNOB 0 AU parameter to trigger randomization. The last knob sets the outbound channel for the cc messages.

https://www.dropbox.com/s/e3ny0ui8mduanxz/MIDI CC Randomizer.mozaic?dl=0

@wim Not only are your creations useful but I learn so much by studying your coding. Top stuff 🙂

Carnbot

Definitely something I’m hoping for too

@wim said:

@Billflinton said:
Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately?

You beat me to it.

I was thinking of suggesting something like that too. Keeping the existing views, but adding one that divided into three or four panels, each configurable to be knobs, sliders, pads, or XY.

Is it possible to have as many unique pages as you want of the different layouts?

So you can flip between multiple sliders pages for example?

If it allowed full screen customisable UI, then it could be more suitable for coding unique controllers, a lot easier than plugins but the fixed guis makes this limited currently. Really hope personally it gets that one day. I bet it would sell loads more with that functionality too as I think many people would use it for that over plugin coding.

brambos

@Carnbot said:
Definitely something I’m hoping for too

@wim said:

@Billflinton said:
Anyway, here’s an idea: how about splitting the space into halves or quarters and making it possible to assign different minilayouts to them separately?

You beat me to it.

I was thinking of suggesting something like that too. Keeping the existing views, but adding one that divided into three or four panels, each configurable to be knobs, sliders, pads, or XY.

Is it possible to have as many unique pages as you want of the different layouts?

So you can flip between multiple sliders pages for example?

If it allowed full screen customisable UI, then it could be more suitable for coding unique controllers, a lot easier than plugins but the fixed guis makes this limited currently. Really hope personally it gets that one day. I bet it would sell loads more with that functionality too as I think many people would use it for that over plugin coding.

Yeah, I think the wish is clear, but I have a feeling this is an example case of "careful what you wish for".

Total freedom is very often not fun, and lots of work. Within the goals that I set out to achieve my current solution does what it needs to (fire one line of code and have a working GUI) and more complex setups will only get in the way of those objectives.

I have used Lemur enough to know that setting up the GUI and hooking up all the controls to make them accessible in script was a massively tedious task, even when using the desktop tools. So for now I'm staying away from such use cases.

(but never say never)

TheOriginalPaulB

How about being able to hide/reveal controls using a dropdown list? That way you could release a super template with overlapping controls all over the shop and users could just activate the ones that they want to use in the positions that suit them.

wim

These are AU plugins. You can have as many instances as you want. I don’t feel the need for increased number of controls in each instance is as important as people think.