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

McD

One more @brambos story:

I spent a few days making a sequence and today I discovered @brambos included an example script that work suspiciously like mine. This means I can read files without opening them. I won't read the @brambos code... I learn more by just hacking away making a script
no programmer should ever read. @_ki saw one of my scripts and asked "Do you mind if I
re-write this?" The ideas were interesting and he showed me why he gets paid to code.

It's like playing chess... only most of us are using checkers rules and don't realize we never actually learned the rules. Still... I have a box of Queens and Kings that I have jumped over.
Of course, I play white and black so I always win.

_ki

@Synthi I‘m making good progress at the multi-divisi script.

I now have something running for 4 to 9 output slots that can cope with the notes played after the initial configuration. One can play normal, legato, or even issue note re-triggers during a single input timeframe. The output usually happens in the same timeframe/midi event‘s systemtime as the input event, even though the script first collects all input of a given input timeframe.

Using heavy wiggling wih 4 fingers on AUMs keyboard, i manage to archive up to 17 midi events in a single event timeframe, lots of re-triggerin of the same notes or ‚short‘ notes with on/off/on/off states. The divisi output is still consitent even with such extreme input.

I already did a hell lot of debugging: The internal state verification code is nearly as long as he other code, the internal state/the decisions/the changes etc are output to logging and if any inconsitency is detected, an emergency fullstop comes into play that stops any further processing.
After inspection of these logs and states, i ususally come up with and idea what went wrong - i then change the slot distribution or midi analysis code and add even futher verfication tests.

The cool thing is that i couldn’t yet ‚brake’ the current version

There are still some features that i want to add to the script, like full MPE support for the input. But all the basic problems mentioned in my initial midi-divisi response are solved.

.

@McD
I‘m not good at chess at all - even if i would play play both sides the game would either last until there are two kings left, or at some point I would decide to let other me win, or i suddenly notice that one of the kings is in check-mate and i don‘t know how i did that

Poppadocrock

@orchid said:
Hey all, I just released 3 new plugins on Patchstorage:

Gravity delay: https://patchstorage.com/gravity-delay/
Panning gravity delay: https://patchstorage.com/panning-gravity-delay/
Dedupe: https://patchstorage.com/dedupe/

I recorded myself setting up the signal chain in AUM and playing a few notes into it:

I’m having a ton of fun with these plugins. Let me know if you make anything cool with them, I’d love to hear

These are really cool, Cheers @orchid

Synthi

@_ki said:
@Synthi I‘m making good progress at the multi-divisi script.

I now have something running for 4 to 9 output slots that can cope with the notes played after the initial configuration. One can play normal, legato, or even issue note re-triggers during a single input timeframe. The output usually happens in the same timeframe/midi event‘s systemtime as the input event, even though the script first collects all input of a given input timeframe.

Using heavy wiggling wih 4 fingers on AUMs keyboard, i manage to archive up to 17 midi events in a single event timeframe, lots of re-triggerin of the same notes or ‚short‘ notes with on/off/on/off states. The divisi output is still consitent even with such extreme input.

I already did a hell lot of debugging: The internal state verification code is nearly as long as he other code, the internal state/the decisions/the changes etc are output to logging and if any inconsitency is detected, an emergency fullstop comes into play that stops any further processing.
After inspection of these logs and states, i ususally come up with and idea what went wrong - i then change the slot distribution or midi analysis code and add even futher verfication tests.

The cool thing is that i couldn’t yet ‚brake’ the current version

There are still some features that i want to add to the script, like full MPE support for the input. But all the basic problems mentioned in my initial midi-divisi response are solved.

That sound wonderful!!! ...you are a genius!
Thanks a lot @_ki

orchid

@McD said:

Deletion is life. It's all practice for the last act.

😁 reminds me of https://deletionday.com, which is coming up soon.

@Poppadocrock said:

These are really cool, Cheers @orchid

Really glad you’re enjoying them!

espiegel123

Has anyone written any scripts that send 14-bit midi?

Alfred

@espiegel123 Yes, it is called bipolarSplitter. It converts pitchbend, up and down into two pairs of 14 bit cc's.

espiegel123

@Alfred said:
@espiegel123 Yes, it is called bipolarSplitter. It converts pitchbend, up and down into two pairs of 14 bit cc's.

Is that script yours? If so, I have a question. There is a place where if MIDIByte 3 > 64 it uses a different set of cc numbers. I was wondering if you could explain?

_ki

@espiegel123 Just from the context mentioned, i suspect that‘s where the ‚bipolar and splitting’ aspect of the script comes to play: A pitchbend down is send on one pair 14 bit CCs and the pitchbend up (ie MIDIByte3 > 64) is send to another CC pair - ie splitting both pitchbend directions.
There is probably also some logic that ‚reset‘ the respective other CC pair to 8192 if the center is crossed - otherwise the other CC pair would stop at that last value send before the crossing happened

_ki

I just checked that script and my assumption was correct - the code line mentioned is responsible for the splitting of up-wards and down-wards pitchbend.

The each CC pair will stay at the last pitchbend value send before the crossing - this can even be an advantage, e.g. if you move the PitchBend wheel quickly from top to bottom, the top value (used for instance for the filter) could stay on a higher value while then influencing the other modulation destination.

espiegel123

@_ki said:
I just checked that script and my assumption was correct - the code line mentioned is responsible for the splitting of up-wards and down-wards pitchbend.

The each CC pair will stay at the last pitchbend value send before the crossing - this can even be an advantage, e.g. if you move the PitchBend wheel quickly from top to bottom, the top value (used for instance for the filter) could stay on a higher value while then influencing the other modulation destination.

Thanks.

I am about to cobble something together to split values (0...16383) into MSB and LSB.

Is this logic right?

Let’s call the value to convert 14bitValue (And assume it is in range)

To get the MSB

temp = 14bitValue * 2 //shifts bits 1 left. Needed to get bit 8 into MSB
MSB = (temp & 0x00FF00) / 0x100 //mask off LSB and shift right 8

To get LSB
LSB = (temp & 0x0000FF) / 2 //masks off MSB and shifts bits back to the right.

_ki

Hmm, on a first glance you conversion code seems fine. I but’ll check with some test examples in mozaic - the back conversion for sure is value = bytes2 + 128*byte3 and bytes are in range 0 to 127.

... a bit later:

Your code works - but i think a shorter conversion is

  MSB = Div Value, 128  // Shift 7 bits right to move the upper 7 bits in position
  LSB = Value & 0x7F    // Mask out the lower 7 bits

.

.

Here is the test code, i used to check if the conversions worked

@OnLoad
  for i = 0 to 1000
    value = Random 0, 16383
    Call @ConvB    // or ConvA
    Call @TestConv
  endfor
  Log {---done---}
@End
 
@ConvA //param: Value out: MSB, LSB
  temp = Value * 2                // shifts bits 1 left. Needed to get bit 8 into MSB
  MSB  = (temp & 0x00FF00) / 0x100//mask off LSB and shift right 8
  LSB  = (temp & 0x0000FF) / 2    //masks off MSB and shifts bits back to the right.
@End
 
@ConvB //param: Value out: MSB, LSB
  MSB = Div Value, 128
  LSB = Value & 0x7F
@End
 
@TestConv // param Value, MSB, LSB
  check = LSB + 128*MSB
  if check <> Value or LSB<0 or LSB>127 or MSB<0 or MSB>127
    Log {Error: pVal=},pVal, {  pLSB=},pLSB, {  pMSB=},pMSB
  endif
@End

Alfred

Thanks @_ki for the review :-)
When you use a wheel it physicaly automaticly resets to the center value.
When using a touchstrip bender it might be possible to skip sending the center position.

@espiegel123
When I reviewed my code just now I noticed a mistake. You have to send the lsb first, because when you send the msb the receiver sets the total value of msb + lsb.

Alfred

Still trying to grasp that bitshifting stuff allthough you guys did a great job explaining it before.
For my own sanity I would use modulus.
Lsb = value % 128

espiegel123

@Alfred said:
Thanks @_ki for the review :-)
When you use a wheel it physicaly automaticly resets to the center value.
When using a touchstrip bender it might be possible to skip sending the center position.

@espiegel123
When I reviewed my code just now I noticed a mistake. You have to send the lsb first, because when you send the msb the receiver sets the total value of msb + lsb.

Thanks! Btw: I was looking at the code in preparation to do the opposite -> turn Mozaic knob values into two 7-bit (MSB and LSB) values. And when that is working, I'd like to figure out a slewing method so that if one has a 7-bit midi knob (like on my Launchkey), it can do some smart slewing fill in values as you turn the dial up or down

lukesleepwalker

I just searched PatchStorage but didn't find anything that does this: I want to define an input note (say C3) and then define a set number of specific notes that can play randomly. So, something like this:

Play C3.
25% chance C3 plays
25% chance E3 plays
25% chance G3 plays
25% chance A3 plays

The script would allow for between 2-7 different scenarios/percentages from 50/50 to ~15% for each note. Velocity, gate, etc remain the same as input.

Alfred

Maybe you can use two 7 bit knobs like tune and finetune.
Slewing by midi is not a good idea because of midi data overload.
Synths dont like to be micromanaged like that.
Have a look at my dataReducer script.

For slewing you could maybe store the recieved lsb and msb in two arrays. And the play them back at a fixed rate.

Most controllers can send cc and pitchbend at a very high rate when moved quickly.
Most daws do data thining like in my script to protect against midi data overload.

espiegel123

@Alfred said:
Maybe you can use two 7 bit knobs like tune and finetune.
Slewing by midi is not a good idea because of midi data overload.
Synths dont like to be micromanaged like that.
Have a look at my dataReducer script.

For slewing you could maybe store the recieved lsb and msb in two arrays. And the play them back at a fixed rate.

Most controllers can send cc and pitchbend at a very high rate when moved quickly.
Most daws do data thining like in my script to protect against midi data overload.

I already have a two knobs (MSB plus LSB) solution. The reason I want to to implement a one knob solution is that two knobs makes the performance cumbersome. And I don't have at my disposal a set of 16 pitchbend wheels. So, I am hoping that I can come up with a scheme to do some smart interpolating/slewing to make a more performer-friendly control.

The slewing script would use a controllable timer to let the user thin the stream so as not to overwhelm the receiving device and to allow customizing the ramping. With two knobs there is no way around zippering and a certain kind of jitter -- and from a performance standpoint it requires two hands in coordination to do something I am preferring to do with one hand.

Is there something particular I would get out of your dataReducer script if I already have a script that thins a MIDI stream to a preferred data rate?

Alfred

Ok I get what you want. Yeah maybe nothing, maybe another perspective you could get out of it. It contains the secret of the dropframe...

mbncp

Any idea what could be crashing all my Mozaic plugs in Drambo (showing error) ? The project was working fine and I see no software change.
Except 2 instances that are a little heavier, all scripts are just a few lines long (19 instances altogether).
First time I see this. I have 1.3 GB of Inactive memory(RAM) and even 100 mb Free left.

mbncp

@brambos
Just a little question regarding cubasis.
OnNewBar, is the HostBar value provided by the HOST ?
The problem is that if I have a 4 bar loop, HostBar will show 0,1,2,3, 4,1,2,3, 4,1,2,3 ...
Now if I start a 1 msec Timer in OnNewBar I will get the right HostBar 0,1,2,3, 0,1,2,3, 0,1,2,3 ...
It's probably a Cubasis thingy but just wanted to make sure before my lawyers contact @Lars and co
Thanks.

_ki

I just notices that i forgot to announce the release ofthe Multi Divisi script some time ago.

Splits and clones midi into separate channels to maximise the usage of 3-10 output voices to achieve a fatter sound whenever possible.

Single notes or chords will choose an pitch-ordered optimal initial distribution using all available voices. As long as one of the notes is sustained, adding or releasing notes will continously update the voice slots using complex optimization strategies. An intermediate release of all keys ends the current distribution run and the next note(s) will start with a new optimal initial configuration.

The script suppports multi channel midi. Controllers and expressions are only routed to voices originating from the same channel. The pitchbend / aftertouch / slide (CC-74) / modwheel (CC-1) / expression (CC-11) are tracked per channel and updated on channel changes before a new note on. In MPE mode, controllers and expressions of channel 1 are routed to all slots and in addition tracked expressions are summed with the channels expressions.

.

One of its use-cases it to setup a SWAM Brass ensemble with six different brass instruments listening on different midi channels and panned to different positions - it sounds really fat when playing monophonic melody lines and still allows to play fat chords etc.

I also did a SWAM String ensemble setup with 4 violins that sounded very cool - but i also had to tweak their settings add some external FX to make these sound like an ensemble.

One rule of thumb for the Multi Divisi script is that there always should at about two more voice instances than the number of the average concurrent notes (# chord-notes) . The script supports note stealing etc, so its not a technical limititation - it just sounds fatter if several notes are play in unison.

.

I tried to do videos about both setups, but seem to fail again and again in their completion... that‘s why i now decided to do this post.

_ki

And i uploaded a ATOM Pattern Switcher & Randomizer script for Mozaic to PatchStorage

Pattern switcher for Atom Pianoroll² with randomization to generate melody and beat variations.

Direct the midi output of the script to a ATOM Pianoroll² instance that contains several pattern and dial the ﹟𝘱𝘢𝘵𝘵𝘦𝘳𝘯𝘴 Knob to the exact number of pattern used in the ATOM instance.
Taping a 𝘗𝘢𝘵 # pad toggles pattern latching. If unlatched, the script can issue synced random pattern changes if configured.

_ki

I just uploaded v1.2 of Smart Chord Bass with a bug fix for state saving. Thanks to @ccs2 for reporting

The previous v1.1 was released december 2019, quite some time ago. The bug itself was a simple typo

Poppadocrock

@_ki said:
I just uploaded v1.2 of Smart Chord Bass with a bug fix for state saving. Thanks to @ccs2 for reporting

The previous v1.1 was released december 2019, quite some time ago. The bug itself was a simple typo

Yes, this is a good one.

Sweet one Atom one too, great stuff.

soundtemple

@brambos Getting some unexpected behaviour with the Lydian scale. Set root to C and ScaleQuantize C yields D. Am I missing something or could this a bug?
Also, any chance you could add in the Locrian scale, seems to be the only missing major mode.

@OnLoad
  PresetScale 9
  SetRootNote 0
  Log (ScaleName 9) , { Quantize: }, (NoteName 0), { ==> }, (NoteName (ScaleQuantize 0), YES)
@End

Lydian Quantize: C ==> D-1

TheOriginalPaulB

I suspect you’ll be told to implement Locrian either as a custom scale, or as a major scale with the root a semitone higher than your intended root.

CalCutta

edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

Hi @brambos ! Since this thread got upped, wanted to put my request here:

If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

wim

@CalCutta said:
edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

Hi @brambos ! Since this thread got upped, wanted to put my request here:

If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

I can't imagine any app or hardware that wouldn't freak out at receiving the blast of PC messages that LFO would put out. Have you seen how fast those suckers come out? Even on a slow LFO speed, it's sending out repeated messages like every 10 ms.

But, assuming the target could handle it, it's easy to convert cc to program change using Mozaic:

Mozaic:

@Description
Demo - convert CC 13 on MIDI channel 1 to program change.
@End

@OnMidiCC
  if MIDIByte2 = 13 and MIDIChannel = 0
    SendMIDIProgramChange MIDIChannel,MIDIByte3
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
  if MIDICommand <> 0xB0
    SendMIDIThru 
  endif
@End

It could be done in Streambyter as well.

# StreamByter Demo: Convert CC 13 on MIDI channel 1 to program change
B0 $13 = C0 X3

CalCutta

@wim said:

@CalCutta said:
edit: Sorry just woke up and totally misread this thread as the Rozeta thread. D'oh!

Hi @brambos ! Since this thread got upped, wanted to put my request here:

If possible, can Program Change be an option in LFO, along with the CC's? So one lane in LFO would just trigger Program Changes.

I would really like to use that with a Critter & Guitari Eyesy. It would be a perfect companion piece with that capability. Thanks!

I can't imagine any app or hardware that wouldn't freak out at receiving the blast of PC messages that LFO would put out. Have you seen how fast those suckers come out? Even on a slow LFO speed, it's sending out repeated messages like every 10 ms.

But, assuming the target could handle it, it's easy to convert cc to program change using Mozaic:

Mozaic:

@Description
Demo - convert CC 13 on MIDI channel 1 to program change.
@End

@OnMidiCC
  if MIDIByte2 = 13 and MIDIChannel = 0
    SendMIDIProgramChange MIDIChannel,MIDIByte3
  else
    SendMIDIThru
  endif
@End

@OnMidiInput
  if MIDICommand <> 0xB0
    SendMIDIThru 
  endif
@End

It could be done in Streambyter as well.

# StreamByter Demo: Convert CC 13 on MIDI channel 1 to program change
B0 $13 = C0 X3

Critter & Guitari Eyesy which doesn't handle audio (video synth) I've been doing it now with a Squarp Pyramid to change scenes and it gives amazing results!

Thanks for the script!