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

Shabudua

@chalice said:

@Shabudua said:

@espiegel123 said:

@wim said:

@Shabudua said:
Why doesn’t this script work?

This is a simple channel 0 panic button, from page 67 of the Mozaic manual. But when I run it, my ears (and MIDI monitor) say it does absolutely nothing.

    @OnShiftDown  
        for nn = 0 to 127
          SendMIDINoteOff 0, nn, 0
        endfor
    @End

The strange part is, if I change the 127 to a smaller number, like 50, it works exactly as expected: press SHIFT and it sends note-off messages for notes 0 to 50 on channel 0, again as comfirmed by MIDI Monitor (and my ears). I can set it as high as 84 and it still works, but 85 or higher gives me nothing. Can anyone else confirm this? I’m hosting Mozaic in AUM.

Works in Audiobus at 127. Doesn’t work in AUM, just as you said. Maybe too many notes at once for AUM to handle?

If you put a minuscule pause after each note does it work?

I tried 1ms and it didnt work. I’ll try something higher.

@OnShiftDown
for nn = 0 to 127
SendMIDINoteOff 0, nn, 0, nn
endfor
@End

Should work

Yeah, that did the trick! The delay parameter works differently than I thought.

Edit: wait, not exactly. It still skipped about half the notes. I’ll try doubling the delay.

mojozart

There is also an All Notes Off message. I recall this was discussed before.

https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message

Shabudua

@mojozart said:
There is also an All Notes Off message. I recall this was discussed before.

https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message

😦...good to know! 😆

wim

Not all synths support it, so a brute-force method isn’t a bad thing to have as a backup.

It’s interesting that AudioBus could handle all the simultaneous Note Off messages without a hiccup and AUM couldn’t.

Bryan

@Shabudua said:
Why doesn’t this script work?

This is a simple channel 0 panic button, from page 67 of the Mozaic manual. But when I run it, my ears (and MIDI monitor) say it does absolutely nothing.

    @OnShiftDown  
        for nn = 0 to 127
          SendMIDINoteOff 0, nn, 0
        endfor
    @End

The strange part is, if I change the 127 to a smaller number, like 50, it works exactly as expected: press SHIFT and it sends note-off messages for notes 0 to 50 on channel 0, again as comfirmed by MIDI Monitor (and my ears). I can set it as high as 84 and it still works, but 85 or higher gives me nothing. Can anyone else confirm this? I’m hosting Mozaic in AUM.

Try this instead:

@OnShiftDown

  for x = 0 to 15
    SendMIDICC x, 123, 0 
  endfor

@End 

This will send the midi “all notes off” message to all channels. Obviously, if you only want to kill all the notes on only one channel, you can skip the for loop and specify the channel directly in place of x.

Peblin

@wim said:

@Peblin said:
@brambos; Adding to the feature requests; one thing I'd really like is the notion of a global timestamp, like CurrentTimeMillis in Java.

I want to be able to do stuff in OnMidiNoteOn like
SetNoteState 0, note, CurrentTimeMillis

and then later save note duration on OnMidiNoteOff with something like
duration = CurrentTimeMillis - (GetNoteState 0, note)

This would be awesome for things like unquantized looping and similar stuff.

I realize that this can be "hacked" using my own timers or high PPQN, but that doesn't feel right from a CPU usage perspective and I also have other uses for the Mozaic timer that it's better suited for (like measuring pad hold times using -ki's script).

Sorry, could be my lack of programming training, but I don’t understand the advantage of this. You would still have to run a loop to check the time constantly to do things, so it seems much same as using the timer. Something like the below seems like it would be just as good, and as many timers as you like could be used.

Not really - if you have a ”global” accessible timestamp you don’t need a loop at all to store note timings, you just grab the timer value when you need it. Your @OnTimer triggers every 1ms, times number of instances of Mozaic, which will have CPU/battery consequences.

My code above only runs in for example @OnMidiNoteOn, no looping, no CPU impact whatsoever.

I have very little experience with realtime ”sample-accurate” programming so maybe the 1ms @OnTimer trigger has no or very little impact, in that case I’ll be happy to use your code as a workaround. But it doesn’t feel right to ”waste” CPU cycles when it’s not necessary, especially in ”multi-tenant” environments like AUv3 hosts where every plugin need to be as well-behaved as possible to allow for the others to work fine.

brambos

@Peblin said:

@wim said:

@Peblin said:
@brambos; Adding to the feature requests; one thing I'd really like is the notion of a global timestamp, like CurrentTimeMillis in Java.

I want to be able to do stuff in OnMidiNoteOn like
SetNoteState 0, note, CurrentTimeMillis

and then later save note duration on OnMidiNoteOff with something like
duration = CurrentTimeMillis - (GetNoteState 0, note)

This would be awesome for things like unquantized looping and similar stuff.

I realize that this can be "hacked" using my own timers or high PPQN, but that doesn't feel right from a CPU usage perspective and I also have other uses for the Mozaic timer that it's better suited for (like measuring pad hold times using -ki's script).

Sorry, could be my lack of programming training, but I don’t understand the advantage of this. You would still have to run a loop to check the time constantly to do things, so it seems much same as using the timer. Something like the below seems like it would be just as good, and as many timers as you like could be used.

Not really - if you have a ”global” accessible timestamp you don’t need a loop at all to store note timings, you just grab the timer value when you need it. Your @OnTimer triggers every 1ms, times number of instances of Mozaic, which will have CPU/battery consequences.

My code above only runs in for example @OnMidiNoteOn, no looping, no CPU impact whatsoever.

I have very little experience with realtime ”sample-accurate” programming so maybe the 1ms @OnTimer trigger has no or very little impact, in that case I’ll be happy to use your code as a workaround. But it doesn’t feel right to ”waste” CPU cycles when it’s not necessary, especially in ”multi-tenant” environments like AUv3 hosts where every plugin need to be as well-behaved as possible to allow for the others to work fine.

(Following this discussion with interest)

So I see how you could use the milliseconds timestamp for capturing events OnMidiInput, but what event would you then use for playing back the loop with the correct timing?

I suppose you could set the timer between each following event with a different interval and only let it trigger once. Or would you quantize the input and use a fixed-interval timer for playback?

wim

@Peblin said:

@wim said:

@Peblin said:
@brambos; Adding to the feature requests; one thing I'd really like is the notion of a global timestamp, like CurrentTimeMillis in Java.

I want to be able to do stuff in OnMidiNoteOn like
SetNoteState 0, note, CurrentTimeMillis

and then later save note duration on OnMidiNoteOff with something like
duration = CurrentTimeMillis - (GetNoteState 0, note)

This would be awesome for things like unquantized looping and similar stuff.

I realize that this can be "hacked" using my own timers or high PPQN, but that doesn't feel right from a CPU usage perspective and I also have other uses for the Mozaic timer that it's better suited for (like measuring pad hold times using -ki's script).

Sorry, could be my lack of programming training, but I don’t understand the advantage of this. You would still have to run a loop to check the time constantly to do things, so it seems much same as using the timer. Something like the below seems like it would be just as good, and as many timers as you like could be used.

Not really - if you have a ”global” accessible timestamp you don’t need a loop at all to store note timings, you just grab the timer value when you need it. Your @OnTimer triggers every 1ms, times number of instances of Mozaic, which will have CPU/battery consequences.

My code above only runs in for example @OnMidiNoteOn, no looping, no CPU impact whatsoever.

I have very little experience with realtime ”sample-accurate” programming so maybe the 1ms @OnTimer trigger has no or very little impact, in that case I’ll be happy to use your code as a workaround. But it doesn’t feel right to ”waste” CPU cycles when it’s not necessary, especially in ”multi-tenant” environments like AUv3 hosts where every plugin need to be as well-behaved as possible to allow for the others to work fine.

I see. Yes, on further thought, I can think of several ways this would be useful. I was only seeing it from the perspective of triggering events, not measuring their duration. Measuring round-trip midi latency, calculating offsets and real-time adjusting for hardware timing drift, calculating and adjusting tempo independent of host tempo, providing feedback about timing accuracy of one’s playing, building groove templates from midi input...

Yep. I like it!

brambos

@pejman said:
Is this still a mozaic bug or cubasis bug or pejman bug ?

I am looking into this, but I still haven’t been able to reproduce this.

Presets saved in Cubasis are identical to presets saved in a state or in the plugin filesystem, so that shouldn’t be the cause - unless it’s a bug in Cubasis. But everything is working as expected on my end.

brambos

I have solved the code-editor-memory-hogging problem! Typical memory footprint for the plugin is now <12 mb. per instance, regardless of the script’s length.

Fontsize preferences are also preserved now.

Harro

@brambos said:
I have solved the code-editor-memory-hogging problem! Typical memory footprint for the plugin is now <12 mb. per instance, regardless of the script’s length.

Fontsize preferences are also preserved now.

I hope you also solved the disappearing textcursor in the editor when you've reached the bottom of the screen (happens with IOS keyboard or bluetooth keyboard)?

brambos

@Harro said:

@brambos said:
I have solved the code-editor-memory-hogging problem! Typical memory footprint for the plugin is now <12 mb. per instance, regardless of the script’s length.

Fontsize preferences are also preserved now.

I hope you also solved the disappearing textcursor in the editor when you've reached the bottom of the screen (happens with IOS keyboard or bluetooth keyboard)?

That one is harder than you might expect because text/keyboard components inside plugins behave differently from standalone apps. So the standard “scroll into view” functionality doesn’t work. Probably because they have no clue where on the screen the cursor is and where it is relative to the keyboard.

Peblin

@brambos said:
So I see how you could use the milliseconds timestamp for capturing events OnMidiInput, but what event would you then use for playing back the loop with the correct timing?

I suppose you could set the timer between each following event with a different interval and only let it trigger once. Or would you quantize the input and use a fixed-interval timer for playback?

I don't need events, someone really clever implemented things like SendMiniNoteOn with optional delay.

So let's imagine (purely hypotetically of course...) that you want to build an OP-Z-like sequencer that allows for "exact" live recording. The OnMetroPulse could trigger on every step (say, 1/16th) and keep track of the step being sequenced as well as the CurrentTimeMillis of the pulse. When OnMidiNote arrives, I can then keep track of the delay with which I want to trigger the note by just measuring elapsed time since last pulse. Then measuring the elapsed time since note on in the OnMidiNoteOff I can also replay the note exactly as played. Very, very nice imo

@wim said:
I see. Yes, on further thought, I can think of several ways this would be useful. I was only seeing it from the perspective of triggering events, not measuring their duration. Measuring round-trip midi latency, calculating offsets and real-time adjusting for hardware timing drift, calculating and adjusting tempo independent of host tempo, providing feedback about timing accuracy of one’s playing, building groove templates from midi input...

Yep. I like it!

Some really awesome examples there that I'd never thought of!

Harro

@brambos said:

@Harro said:

@brambos said:
I have solved the code-editor-memory-hogging problem! Typical memory footprint for the plugin is now <12 mb. per instance, regardless of the script’s length.

Fontsize preferences are also preserved now.

I hope you also solved the disappearing textcursor in the editor when you've reached the bottom of the screen (happens with IOS keyboard or bluetooth keyboard)?

That one is harder than you might expect because text/keyboard components inside plugins behave differently from standalone apps. So the standard “scroll into view” functionality doesn’t work. Probably because they have no clue where on the screen the cursor is and where it is relative to the keyboard.

Thank you, Bram, I understand. Although this disappearing cursor also happens in Mozaic standalone... (f.e. the Notes editor in AUM works as expected).
One other thing: could you please make the User Patches preset-list order case INsensitve? Because now it's case sensitive and that's confusing (infinity-0.4 comes after Velocity MIDI Echo!).

brambos

@Harro said:

@brambos said:

@Harro said:

@brambos said:
I have solved the code-editor-memory-hogging problem! Typical memory footprint for the plugin is now <12 mb. per instance, regardless of the script’s length.

Fontsize preferences are also preserved now.

I hope you also solved the disappearing textcursor in the editor when you've reached the bottom of the screen (happens with IOS keyboard or bluetooth keyboard)?

That one is harder than you might expect because text/keyboard components inside plugins behave differently from standalone apps. So the standard “scroll into view” functionality doesn’t work. Probably because they have no clue where on the screen the cursor is and where it is relative to the keyboard.

Thank you, Bram, I understand. Although this disappearing cursor also happens in Mozaic standalone..

But the standalone container is a simple AU host which loads the plugin. So it just looks like a standalone but it’s actually the plugin running

Harro

Got it! ( )

badbeat

Anyone know if it's possible to code a portamento note slider script that adds it for synths that don't? Very useful for drum synths like ruismaker noir and synth drum 808 slides!

wim

@badbeat said:
Anyone know if it's possible to code a portamento note slider script that adds it for synths that don't? Very useful for drum synths like ruismaker noir and synth drum 808 slides!

That should be possible as long as the apps in question respond to pitch bend messages. Just detect note overlap and send pitch bend between the two notes over the range of the overlap.

I haven’t tested whether noir or synth drum respond to pitch bend though.
[edit] Looks like they don’t. So no-go on those two at least.

badbeat

@wim said:

@badbeat said:
Anyone know if it's possible to code a portamento note slider script that adds it for synths that don't? Very useful for drum synths like ruismaker noir and synth drum 808 slides!

That should be possible as long as the apps in question respond to pitch bend messages. Just detect note overlap and send pitch bend between the two notes over the range of the overlap.

I haven’t tested whether noir or synth drum respond to pitch bend though.
[edit] Looks like they don’t. So no-go on those two at least.

Thanks for checking out Wim. Any chance of adding that to Noir @brambos ?

craftycurate

Are the following scenarios possible in Mozaic?

1) Filter incoming MIDI and only pass through the lowest note? (e.g. bass note generator from chord)

2) An Arpeggiator which can play multiple notes per step. So let's say there are 4 incoming MIDI notes, N1 to N4 (from low to high) ... so on each arp measure we'll play a selection of those notes e.g.

Measure 1: N1
Measure 2: N2 + N4
Measure 3: N1 + N2 + N3
Measure 4: N4

Ideally this would be set using a grid editor of some kind (e.g. as in StepPolyArp app) but maybe in a future version of Mozaic.

Thanks in advance
Richard

wim

@craftycurate said:
Are the following scenarios possible in Mozaic?

1) Filter incoming MIDI and only pass through the lowest note? (e.g. bass note generator from chord)

Yes, but there would need to be some kind of timing threshold to determine whether two notes should be considered simultaneous or not.

2) An Arpeggiator which can play multiple notes per step. So let's say there are 4 incoming MIDI notes, N1 to N4 (from low to high) ... so on each arp measure we'll play a selection of those notes e.g.

Measure 1: N1
Measure 2: N2 + N4
Measure 3: N1 + N2 + N3
Measure 4: N4

Ideally this would be set using a grid editor of some kind (e.g. as in StepPolyArp app) but maybe in a future version of Mozaic.

Why when SPA already does this?

Thanks in advance
Richard

craftycurate

@wim said:

@craftycurate said:
Are the following scenarios possible in Mozaic?

1) Filter incoming MIDI and only pass through the lowest note? (e.g. bass note generator from chord)

Yes, but there would need to be some kind of timing threshold to determine whether two notes should be considered simultaneous or not.

2) An Arpeggiator which can play multiple notes per step. So let's say there are 4 incoming MIDI notes, N1 to N4 (from low to high) ... so on each arp measure we'll play a selection of those notes e.g.

Measure 1: N1
Measure 2: N2 + N4
Measure 3: N1 + N2 + N3
Measure 4: N4

Ideally this would be set using a grid editor of some kind (e.g. as in StepPolyArp app) but maybe in a future version of Mozaic.

Why when SPA already does this?

Thanks in advance
Richard

Because SPA doesn’t have a Random function ... you can’t ask it to select randomly from the notes held down to inject a bit of variation into a Bassline for example.

Also because I have some other similar arpeggiator ideas I’d like to try out.

reasOne

Did I read somewhere that a fresh install comes with more scripts / presets ?

brambos

@reasOne said:
Did I read somewhere that a fresh install comes with more scripts / presets ?

No need to reinstall. Simply updating to the latest version should always bring the up-to-date preset collection.

reasOne

@brambos said:

@reasOne said:
Did I read somewhere that a fresh install comes with more scripts / presets ?

No need to reinstall. Simply updating to the latest version should always bring the up-to-date preset collection.

Rad! Ty

[Deleted User]

@brambos
Do you think midi clock out (with dividers, +/- delay) is achievable in Mozaic framework?
Would be great to be able to start/stop external seqs

wim

@craftycurate said:

@wim said:

@craftycurate said:
Are the following scenarios possible in Mozaic?

1) Filter incoming MIDI and only pass through the lowest note? (e.g. bass note generator from chord)

Yes, but there would need to be some kind of timing threshold to determine whether two notes should be considered simultaneous or not.

2) An Arpeggiator which can play multiple notes per step. So let's say there are 4 incoming MIDI notes, N1 to N4 (from low to high) ... so on each arp measure we'll play a selection of those notes e.g.

Measure 1: N1
Measure 2: N2 + N4
Measure 3: N1 + N2 + N3
Measure 4: N4

Ideally this would be set using a grid editor of some kind (e.g. as in StepPolyArp app) but maybe in a future version of Mozaic.

Why when SPA already does this?

Thanks in advance
Richard

Because SPA doesn’t have a Random function ... you can’t ask it to select randomly from the notes held down to inject a bit of variation into a Bassline for example.

Also because I have some other similar arpeggiator ideas I’d like to try out.

In that case, mechanically, no problem. Interface-wise it I can’t really picture it.

brambos

@wim said:

@craftycurate said:

@wim said:

@craftycurate said:
Are the following scenarios possible in Mozaic?

1) Filter incoming MIDI and only pass through the lowest note? (e.g. bass note generator from chord)

Yes, but there would need to be some kind of timing threshold to determine whether two notes should be considered simultaneous or not.

2) An Arpeggiator which can play multiple notes per step. So let's say there are 4 incoming MIDI notes, N1 to N4 (from low to high) ... so on each arp measure we'll play a selection of those notes e.g.

Measure 1: N1
Measure 2: N2 + N4
Measure 3: N1 + N2 + N3
Measure 4: N4

Ideally this would be set using a grid editor of some kind (e.g. as in StepPolyArp app) but maybe in a future version of Mozaic.

Why when SPA already does this?

Thanks in advance
Richard

Because SPA doesn’t have a Random function ... you can’t ask it to select randomly from the notes held down to inject a bit of variation into a Bassline for example.

Also because I have some other similar arpeggiator ideas I’d like to try out.

In that case, mechanically, no problem. Interface-wise it I can’t really picture it.

Indeed, the algorithm doesn’t sound too difficult, but we’d have to figure out how to ‘get the notes in’.

brambos

@recccp said:
@brambos
Do you think midi clock out (with dividers, +/- delay) is achievable in Mozaic framework?
Would be great to be able to start/stop external seqs

Haven’t tried yet, but it sounds doable. The only issue I see is that perhaps some hosts may filter out clock messages in their internal MIDI streams.

pejman

@wim said:

@pejman said:
I want to have plugin for when i play chords through another app like ( suggester ) connect to cubasis for example, this plugin can play chords with different start notes and different velocity randomly, like humanizing .
I need to control or change maximum value of time random from 0-500 and minimum and maximum values of velocity random each one from 0-127 through knobs. But I don’t know how can or write programs.

Hi @pejman,

I started to work on this, thinking it would be a pretty straightforward modification. I’ve since discovered that it’s a bigger challenge than I thought. The Chordulator is simple because it only needs to track one note. But to act on chords requires detecting what is actually a chord based on how close together their note-on messages happen. That’s easy enough.

But then the notes would be scrambled up into different voicings, timing, and probability. In the meantime, the original notes would be released at some point. The relative timing for the release of the notes would be different. Or a different chord might have been triggered, possibly overlapping timing and sharing some of the same notes. This is only one aspect of where things get complicated. It becomes a nightmare trying to track what is going on to assure there are no stuck notes.

Sorry, I don’t think I’m up for the challenge. Maybe I’ll have a stroke of brilliance and understand how it can be done, but right now I don’t see much chance of success and am putting the idea aside.

Sorry - I know that’s not what you were hoping to hear.

Hi again wim
But one question. Can you create one patch with only ( rand time ) and ( rand vel ) and ( probability ) ? This patch can solve my problem . I have one patch with rand time and rand velocity with brambos help , and then decide to add probability to it . but I cannot add probability to this patch . Perhaps its structure is such that it can not be easily added to this option