Request new Mozaic Scripts *HERE*

wim

@sharifkerbage said:
Is it possible with Mozaic to route the Slide and Aftertouch (pressure) from a Roli Seaboard to send specific CC messages?
If so, is there any existing script for that goal?

That's actually not a straightforward thing to do. MPE doesn't just send on one midi channel. It sends on different channels depending on how many notes are held down. Also, it's not just one stream of all the same aftertouch and pitch-bend messages like a pitch bend wheel or a knob on a controller ... it's simultaneous independent streams coming from each note. You could have pitch bending from -10% to +40% on one note while at the same time another note is sending pitch messages bending from +80 to +10, etc.

I attempted to address these issues in MPE Multiplexer. According to my admittedly non-exhaustive testing, it seems to do a pretty good job of mapping these multi-channel pitch bend and aftertouch messages to single streams of CC's of your choice. I tested it only with a Sensel Morph and with KB-1, not a Seaboard. ymmv.

[edit ... oops. You mentioned aftertouch. MPE Multiplexer is set up by default to deal with slide (CC 74) and pitch bend, not aftertouch. This script might be a good starting point for what you want, but would need to be modified to deal with aftertouch rather than (or in addition to) pitch bend.

I'm going to be traveling for a bit, and also don't have a Seaboard to work with to make it very practical to try to develop for, so if you or anyone else would like to take a crack at a modified or extended version, go for it!]

sharifkerbage

@wim said:

@sharifkerbage said:
Is it possible with Mozaic to route the Slide and Aftertouch (pressure) from a Roli Seaboard to send specific CC messages?
If so, is there any existing script for that goal?

That's actually not a straightforward thing to do. MPE doesn't just send on one midi channel. It sends on different channels depending on how many notes are held down. Also, it's not just one stream of all the same aftertouch and pitch-bend messages like a pitch bend wheel or a knob on a controller ... it's simultaneous independent streams coming from each note. You could have pitch bending from -10% to +40% on one note while at the same time another note is sending pitch messages bending from +80 to +10, etc.

I attempted to address these issues in MPE Multiplexer. According to my admittedly non-exhaustive testing, it seems to do a pretty good job of mapping these multi-channel pitch bend and aftertouch messages to single streams of CC's of your choice. I tested it only with a Sensel Morph and with KB-1, not a Seaboard. ymmv.

Thanks, I'll give it a go with the Seaboard.
So, considering the multiple streams that MPE sends out for each note, is it possible to filter them in a way that Mozaic takes 1 value for aftertouch and 1 value for CC74, and then converting them to another CC value?

wim

@sharifkerbage said:
Thanks, I'll give it a go with the Seaboard.
So, considering the multiple streams that MPE sends out for each note, is it possible to filter them in a way that Mozaic takes 1 value for aftertouch and 1 value for CC74, and then converting them to another CC value?

Yes ... but see the edit's in my above post. I realized afterward that you're interested in converting aftertouch, not pitch-bend.

sharifkerbage

@wim said:

@sharifkerbage said:
Is it possible with Mozaic to route the Slide and Aftertouch (pressure) from a Roli Seaboard to send specific CC messages?
If so, is there any existing script for that goal?

That's actually not a straightforward thing to do. MPE doesn't just send on one midi channel. It sends on different channels depending on how many notes are held down. Also, it's not just one stream of all the same aftertouch and pitch-bend messages like a pitch bend wheel or a knob on a controller ... it's simultaneous independent streams coming from each note. You could have pitch bending from -10% to +40% on one note while at the same time another note is sending pitch messages bending from +80 to +10, etc.

I attempted to address these issues in MPE Multiplexer. According to my admittedly non-exhaustive testing, it seems to do a pretty good job of mapping these multi-channel pitch bend and aftertouch messages to single streams of CC's of your choice. I tested it only with a Sensel Morph and with KB-1, not a Seaboard. ymmv.

[edit ... oops. You mentioned aftertouch. MPE Multiplexer is set up by default to deal with slide (CC 74) and pitch bend, not aftertouch. This script might be a good starting point for what you want, but would need to be modified to deal with aftertouch rather than pitch bend.

I'm going to be traveling for a bit, and don't have a Seaboard to work with to make it very practical to develop for, so if you or anyone else would like to take a crack at a modified or extended version, go for it!]

I'll definitely take that one as starting point, I'm kinda noobie at Mozaic coding and I want to learn more, so it's a good opportunity.
I'm thinking that adding aftertouch instead of replacing pitch bend would be even better.. it'd do CC74, pitch bend and aftertouch to CC.

wim

@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. Here's a totally untested quick pass ... sorry, all I have time for right now.

@Description
Demo - quick guess at a script to convert after pressure and slide on a Roli Seaboard Block to cc 20 and cc 21 respectively.
Assumes Seaboard is in Single Channel Mode, not MPE mode!
Sorry ... this has not been tested.
@End

@OnLoad
  // define the first and second bytes of the outbound message
  pressureMsg = [0xB0, 20]
  slideMsg = [0xB0, 21]
@End

@OnMidiInput
  // remap Afterpressure 
  if MIDIByte1 = 0xD0
    SendMIDIOut pressureMsg[0], pressureMsg[1], MIDIByte3

  // or CC 74 
  elseif (MIDIByte1 = 0xB0) and MIDIByte2 = 74
    SendMIDIOut slideMsg[0],slideMsg[1],MIDIByte3

  else
    SendMIDIThru
  endif

@End

sharifkerbage

@wim said:
@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. That's only a few lines of code.

That would be a quicker solution indeed. But I use it often with MPE synths, so I'd prefer not having to change from MPE to Single Channel every time.

wim

@sharifkerbage said:

@wim said:
@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. That's only a few lines of code.

That would be a quicker solution indeed. But I use it often with MPE synths, so I'd prefer not having to change from MPE to Single Channel every time.

OK, well I whipped up an example above to show how much more straightforward the code would be. You might want to consider the idea. Not that modifying the MPE Multiplexer script would be too horrible bad. But it is a kludge. Certain compromises have to be made when trying to squish conflicting MPE messages into a coherent stream. Much cleaner to handle it at the source IMO, but I understand not wanting to switch modes.

(BTW, the equivalent Single Channel Mode script could be handled in two lines of Streambyter code)

sharifkerbage

@wim said:

@sharifkerbage said:

@wim said:
@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. That's only a few lines of code.

That would be a quicker solution indeed. But I use it often with MPE synths, so I'd prefer not having to change from MPE to Single Channel every time.

OK, well I whipped up an example above to show how much more straightforward the code would be. You might want to consider the idea. Not that modifying the MPE Multiplexer script would be too horrible bad. But it is a kludge. Certain compromises have to be made when trying to squish conflicting MPE messages into a coherent stream. Much cleaner to handle it at the source IMO, but I understand not wanting to switch modes.

(BTW, the equivalent Single Channel Mode script could be handled in two lines of Streambyter code)

Thanks so much! I might try that method first, and then see how intimidating the MPE Multiplexer code results for me 😂

Skyblazer

Hi, I'm looking for a script that will allow me to step through a sequence of pitch bend range settings, using a footswitch. I'd like for 8 patterns of 8 notes to be selectable from the bottom 8 pads, and displayed on the top 8. Finally, I'd like for emojis to be used in the LabelPads field, to reflect the pitch bend value being output. When the Y value of the XY pad is above 0, it should override the sequence and set the bend range, using a small, evenly-spaced palette of values.

I could do it myself, but I was wondering if I could watch somebody else make it, while I sit back and smoke weed. Or you could also contribute ideas? I have a ton of unfinished prototypes. I'm looking for a friendship like the one Ali G described, when he pitched his idea to business experts, to bring the hoverboard from Back to the Future to a wider audience: I come up with the idea, you do the science. I can't afford to offer any compensation, but I'll remember to wish you a happy birthday.

The future is at your fingertips, that's how good my ideas are. Wow, it's an opportunity. Any takers?

Also, who wants to help me design a cell sequencer for Launchpad X, inspired by Rozeta and Drambo? My goal is to create the world's fastest and most intuitive composition method, the easiest way to take a song idea from your head to the piano roll. I want composition to feel as fluid as playing an instrument. My current plan is that the buttons will be used to access a variety of toolbars and other modular functions, so if you don't like my Clipboard Toolbar, or Navigation Toolbar, or system of accessing toolbars, it should be easy to swap it out with your own. Looking for design ideas, DAW shortcuts that you like, frustrations you've had when using a piano roll, or just users who can provide feedback on how my design meshes with their workflow. I can start a topic about it, if anyone's interested. At some point, I'm hoping it will be possible to integrate it seamlessly with Atom 2.

The basic workflow will be: Tap and hold a cell, play a chord, tap another cell to set the length. But I'm also planning to have Reaper shortcut esque buttons, like "duplicate loop, then move timeline selection to select it". So, any shortcuts you use to speed up your note entry workflow are relevant. 😎

wim

@sharifkerbage said:

@wim said:

@sharifkerbage said:

@wim said:
@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. That's only a few lines of code.

That would be a quicker solution indeed. But I use it often with MPE synths, so I'd prefer not having to change from MPE to Single Channel every time.

OK, well I whipped up an example above to show how much more straightforward the code would be. You might want to consider the idea. Not that modifying the MPE Multiplexer script would be too horrible bad. But it is a kludge. Certain compromises have to be made when trying to squish conflicting MPE messages into a coherent stream. Much cleaner to handle it at the source IMO, but I understand not wanting to switch modes.

(BTW, the equivalent Single Channel Mode script could be handled in two lines of Streambyter code)

Thanks so much! I might try that method first, and then see how intimidating the MPE Multiplexer code results for me 😂

I had some downtime to think about this, and it seems like adding support for “Press” (aftertouch) to MPE multiplexer wouldn’t be too hard and would be a good improvement to the script that I’ll probably take on when I have time. That would cover four out of the five Seaboard expressions. “Lift” (release velocity) would be a different animal. I’m not sure that’s worth doing, especially as I have nothing to test it with.

To judge whether or not this is worth doing, maybe let me know if the existing functionality of the MPE Multiplexer script works with the Block, and see if it does what you’d expect it to. This was an experiment, so I don’t really want to bother enhancing it if the thing isn’t actually useful.

wim

@Skyblazer said:
Hi, I'm looking for a script that will allow me to step through a sequence of pitch bend range settings, using a footswitch. I'd like for 8 patterns of 8 notes to be selectable from the bottom 8 pads, and displayed on the top 8. Finally, I'd like for emojis to be used in the LabelPads field, to reflect the pitch bend value being output. When the Y value of the XY pad is above 0, it should override the sequence and set the bend range, using a small, evenly-spaced palette of values.

I'm confused.

• When you say "8 patterns of 8 notes", are you referring to actual notes, like C2, D2, C3, B2, F#2 ...? If so, what would trigger these notes?
• I don't understand what you mean by "pitch bend range settings". Pitch bend is just a series of numbers between 0 and 16,383, with 8192 representing no pitch bend. The effect of this range of numbers is dependent on the synth patch, and Mozaic has no way to know how much pitch change that represents. The only "range" you could set would be to limit the range variation from 8192 (for instance, making it 6192 - 10192). Is that what you mean?
• Or by "pitch bend range" do you mean actual pitch bend values, like a sequence of numbers: 10192, 8192, 6192, ...) which would bend whatever notes are playing on the target synth by that amount?
• Sorry, I really don't know how to decode "... override the sequence and set the bend range, using a small, evenly-spaced palette of values."

I could do it myself, but I was wondering if I could watch somebody else make it, while I sit back and smoke weed.

I might be interested in writing this but maybe help me understand the specification before hitting up the weed too hard. Right now it's a bit muddled.

sharifkerbage

@wim said:

@sharifkerbage said:

@wim said:

@sharifkerbage said:

@wim said:
@sharifkerbage - looking at the Seaboard manual, isn't Single Channel Mode more like what you want? That would make this whole problem so much simpler.

Single Channel Mode
In Single Channel Mode the Block transmits all MIDI data on a single MIDI channel only. This makes it compatible with mono-timbral synths. Pitch bend, channel pressure, or Slide (MIDI CC 74) messages will apply to all notes equally.

Then all you need is a very simple script to convert channel pressure messages and CC 74 messages. That's only a few lines of code.

That would be a quicker solution indeed. But I use it often with MPE synths, so I'd prefer not having to change from MPE to Single Channel every time.

OK, well I whipped up an example above to show how much more straightforward the code would be. You might want to consider the idea. Not that modifying the MPE Multiplexer script would be too horrible bad. But it is a kludge. Certain compromises have to be made when trying to squish conflicting MPE messages into a coherent stream. Much cleaner to handle it at the source IMO, but I understand not wanting to switch modes.

(BTW, the equivalent Single Channel Mode script could be handled in two lines of Streambyter code)

Thanks so much! I might try that method first, and then see how intimidating the MPE Multiplexer code results for me 😂

I had some downtime to think about this, and it seems like adding support for “Press” (aftertouch) to MPE multiplexer wouldn’t be too hard and would be a good improvement to the script that I’ll probably take on when I have time. That would cover four out of the five Seaboard expressions. “Lift” (release velocity) would be a different animal. I’m not sure that’s worth doing, especially as I have nothing to test it with.

To judge whether or not this is worth doing, maybe let me know if the existing functionality of the MPE Multiplexer script works with the Block, and see if it does what you’d expect it to. This was an experiment, so I don’t really want to bother enhancing it if the thing isn’t actually useful.

Man, it works like a charm!! I just tried it out with Sunrizer routing cc74 to the modwheel, beautiful! I like how it manages to send an average value when more than one key on the seaboard is pressed at different slide positions.
I also tried it using the pitch bend to send another cc message, and everything went perfect.
So, green light to add Pressure to it 😃
Thank you so much for this!

wim

Ok @sharifkerbage - glad to hear it works. I just need to think through how best to handle the need for extra knobs. I’ll probably have some time to work on it this week, but not for sure.

sharifkerbage

@wim said:
Ok @sharifkerbage - glad to hear it works. I just need to think through how best to handle the need for extra knobs. I’ll probably have some time to work on it this week, but not for sure.

Cool, take your time! And let me know if you need me to try things out during the process.

Skyblazer

@wim said:

@Skyblazer said:
Hi, I'm looking for a script that will allow me to step through a sequence of pitch bend range settings, using a footswitch. I'd like for 8 patterns of 8 notes to be selectable from the bottom 8 pads, and displayed on the top 8. Finally, I'd like for emojis to be used in the LabelPads field, to reflect the pitch bend value being output. When the Y value of the XY pad is above 0, it should override the sequence and set the bend range, using a small, evenly-spaced palette of values.

I'm confused.

• When you say "8 patterns of 8 notes", are you referring to actual notes, like C2, D2, C3, B2, F#2 ...? If so, what would trigger these notes?
• I don't understand what you mean by "pitch bend range settings". Pitch bend is just a series of numbers between 0 and 16,383, with 8192 representing no pitch bend. The effect of this range of numbers is dependent on the synth patch, and Mozaic has no way to know how much pitch change that represents. The only "range" you could set would be to limit the range variation from 8192 (for instance, making it 6192 - 10192). Is that what you mean?
• Or by "pitch bend range" do you mean actual pitch bend values, like a sequence of numbers: 10192, 8192, 6192, ...) which would bend whatever notes are playing on the target synth by that amount?
• Sorry, I really don't know how to decode "... override the sequence and set the bend range, using a small, evenly-spaced palette of values."

I could do it myself, but I was wondering if I could watch somebody else make it, while I sit back and smoke weed.

I might be interested in writing this but maybe help me understand the specification before hitting up the weed too hard. Right now it's a bit muddled.

Thanks for considering it! I think I'll spend a few days coming up with a design, and I'll get back to you with more details. Here are my thoughts so far. I definitely do want to "limit the range variation from 8192". I'll think some more about what would be the best mod wheel usage. This would work best for apps that offer at least 12 semitone pitch bend, but I'm most looking forward to using it with SWAM and my EWI. The maximum bend range of the synth could be matched in Mozaic: 12, 24, 36, or 48.

Much better than a sequencer, I've thought of two ways to set the range variation so far, and they could both be active simultaneously:

1. Press down on the sustain pedal (or send a different MIDI message), and then play two notes (let's call them Note A and Note B}, in order to set the range variation, to the distance in semitones between those two notes. (These notes aren't SentThru.) If the pitch bend wheel has been moved into the top or bottom third of its range when the second note is played, the range will only be set for upwards or lower bends respectively. If it's in the middle third, the range will be set for both. (It might allow for faster or more expressive play if the "middle zone" is smaller or wider than 1/3, so that would be a nice knob to have.)

2. The range variation is set by user-defined MIDI messages. (This could be paired with any stepping sequencer to get the effect I was envisioning before.) So far, I'm thinking the quickest entry method might be: select a slot by tapping a Mozaic pad, play a MIDI note or CC value to define the message used to select the slot, and then play a second note to set the "range variation" of up or down bends, in a similar manner to option #1. Option 2 is a good feature for anyone whose preferred number of foot pedals/switches <> 1. You could use your pinky to switch between -7/+5 and -1/+12 or something like that.

By default, the RangeVariation/BendRange can be calculated using the absolute value of the distance between Note A and Note B, but the option should be there to create a downward pitch bend when the user moves the wheel upwards, and vice versa. if (LastPitchbend = 16k) and (Note B < Note A), RangeVariation doesn't get Abs() applied to it.

I'll try to clear up the rest of the specifics once I've spent some time making some UI sketches, but if any thoughts come to your mind @wim, (or from anyone else) I'm always interested.

orand

Does anyone have a subroutine that prints an array to the log in hexadecimal format? One example would be to log incoming sysex messages.

orand

@orand said:
Does anyone have a subroutine that prints an array to the log in hexadecimal format? One example would be to log incoming sysex messages.

Upon further investigation, it appears variables don’t support strings, making it impossible or impractical to build this, despite having the necessary math support. But perhaps I’m missing something as a Mozaic newbie.

wim

@orand said:

@orand said:
Does anyone have a subroutine that prints an array to the log in hexadecimal format? One example would be to log incoming sysex messages.

Upon further investigation, it appears variables don’t support strings, making it impossible or impractical to build this, despite having the necessary math support. But perhaps I’m missing something as a Mozaic newbie.

You could do it, but it wouldn't be practical IMO due to the amount of code it would take to do all the substitutions.

_ki

@orand One can display hex dumps „one byte per line“ as in the following SysEx Dump script i just wrote

@Description
▫️◽️◻️⬜️ SysEx Dump v1.0 ⬜️◻️◽️▫️

Simple hexvalue dump utility for System Exclusive MIDI messages. Please switch to LOG view to display incoming sysex messages.
@End

@OnLoad  
  SetShortName {SYSEXD}
  ShowLayout 4

  LabelKnobs { }
  for _knob = 0 to 3
    LabelKnob _knob,{ }
    SetKnobValue _knob,0
  endfor

  // Notename constants
  ABCDEFG[10]   = [9,11,0,2,4,5,7]

  Log {===============================}
  Log {SysEx Dump v1.0}
  Log {===============================}

  count = 1
@End


@OnSysex
  ReceiveSysex pArr

  // Output in reverse for better readability
  Log { }
  Log {  $F7}
  for pIdx = (SysexSize-1) to 0
    Call @LogHexByteEntry
  endfor
  Log {  $F0}
  Log {Received SYSEX #},count,{ (},SysExSize+2,{ bytes)}
  Inc count
@End


@LogHexByteEntry // Parameters: pArr, pIdx
  if pArr[pIdx] < 0 or pArr[pIdx] > 255
    Log {BAD Value pArr[},pIdx,{]},pArr[pIdx]
  else
    // Extract the two nibbles
    _a = Div pArr[pIdx], 16
    _b = pArr[pIdx] % 16

    // There are four variants, each nibble either in range 0-9 or A-F
    if _a < 10 and _b < 10
      Log {  $},_a,_b
    elseif _a < 10
      Log {  $},_a,(NoteName ABCDEFG[_b], NO) 
    elseif _b < 10
      Log {  $},(NoteName ABCDEFG[_a], NO),_b
    else
      Log {  $},(NoteName ABCDEFG[_a], NO),(NoteName ABCDEFG[_b], NO)  
    endif    
  endif
  @End    

.

Since that script might be of general interest, i added it to PatchStorage

orand

Haha!! There are some crazy, awesome hacks going on there! Converting numbers to characters using NoteName array lookup is brilliant. Good thing hex characters are a subset of note names…. The decrementing for loop trick is also great. And sure enough, that’s actually in the documentation. Nice guard code for out-of-range values. Also nice that you re-add the sysex framing bytes, and include those in the byte count.

Thanks a bunch for writing and sharing that. I’m sure others will benefit.

hes

@_ki said:
@orand One can display hex dumps „one byte per line“ as in the following SysEx Dump script i just wrote

I wish there were a second 'Log' command that didn't have an automatic CR/LF at the end. That would make formatting things easier and nicer.

orand

@hes said:

@_ki said:
@orand One can display hex dumps „one byte per line“ as in the following SysEx Dump script i just wrote

I wish there were a second 'Log' command that didn't have an automatic CR/LF at the end. Would make a lot of formatting things easier.

Agreed. That seems like much less work for @brambos than adding support for string variables and all the associated manipulations, which he has said he doesn’t want to do.

_ki

Your idea would help for Logging output, but the main usecase of the old request for at least constant strings arrays or a Char(x) function were dynamic Pad or Knob labels - without the need for long if-cascades for each of the possible strings.

This would only reduce the amount of work for developers of scripts with complex UI ideas and doesn‘t open up completly new Mozaic use-cases. Instead, wishes for more comfort functions (more string functions, layouts, etc.) are aroused and new possible sources of error are added.

hes

@_ki said:
Your idea would help for Logging output, but the main usecase of the old request for at least constant strings arrays or a Char(x) function were dynamic Pad or Knob labels - without the need for long if-cascades for each of the possible strings.

Yes, exactly. I have no hope that any support for strings will be added in the Mozaic interpreter. However, given that the Log command is the main debugging tool, a simple addition like suppressing CR/LF in a Log command seems not so far-fetched.

AlmostAnonymous

Anyone have a best practices for arrays?
Looking to manage a lppmk3 in programmers mode for LED (color + solid/flashing) and button (on/off) states
Having a little difficulty wrapping my head around them.

wim

@AlmostAnonymous said:
Anyone have a best practices for arrays?
Looking to manage a lppmk3 in programmers mode for LED (color + solid/flashing) and button (on/off) states
Having a little difficulty wrapping my head around them.

It might be easier to answer if you can detail what you don't you get. They're just a list of numbers. The first element is numbered 0. You refer to the numbers stored in the array by their index. myArray[2] would return the 3rd number in the array.

AlmostAnonymous

Im having a hard time wrapping my head around it im not even sure what im asking.

1st how to define the array i guess...

myArray = [n, n, n, n, n, ...], this would be probably close to 384 values
or
x,y arrangement? If so, not sure how to accomplish this

So there would be a default state for @OnLoad
each pad on the lpp would need 3 values (midi channel, note number, and velocity) just to illuminate it

McD

@AlmostAnonymous said:
each pad on the lpp would need 3 values (midi channel, note number, and velocity) just to illuminate it

I would define 3 arrays: channel, note, velocity and use a single index to insure all three are
in sync for each insert or recall. I wouldn't swet concerns about extra storage. Some might
put all three values into the same array and always insert and recall them in a "1 to 3" loop.
If you get your code correct either would be fine but I tend to think of extra values I'd like to
add so just spinning up an additional array can let an index refer to many variables each in it's own named array.

The maximum number of values supported in each array is 1024.

AlmostAnonymous

i kinda get where youre going with that.
when you say 1 to 3 loop, you mean define 64 arrays w/ 3 values each?

myArrayPad1 = [n, n, n]
myArrayPad2 = [n, n, n]
myArrayPad3 = [n, n, n]
.....
myArrayPad63 = [n, n, n]
myArrayPad64 = [n, n, n]

this is kidna how my brain works...i know its a TON of extra code writing, which im ok with. But if it helps organize in my head i guess i'm ok with that. i just knwo you guys would all look at it and give a huge eye roll

McD

@AlmostAnonymous said:
i kinda get where youre going with that.
when you say 1 to 3 loop, you mean define 64 arrays w/ 3 values each?

myArrayPad1 = [n, n, n]
myArrayPad2 = [n, n, n]
myArrayPad3 = [n, n, n]
.....
myArrayPad63 = [n, n, n]
myArrayPad64 = [n, n, n]

No, The only array possible is Array_Name[i] = value.
So, using three arrays keeps things easy to manage:
Channel[i] = 0
Note[i] = 40
Velocity = 100

What I mean by the 1 to 3 loop is something like this
channel = 0
note = 40
velocity = 100

num_of_elements = 3
offset = 0
index = (offset * num_of_elements) + ( i - 1)
Array[index] = channel
Array[index+1] = note
Array[index+2] = velocity

I think you can see why just using named arrays for each element is easier to
manage because ONE index can recall a row of values across the arrays all in sync.

@_ki is a master of these concepts and can add a lot of "run time" experience to the
discussion. He can deliver a lesson on packing data into a single variable... one variable might be used to hold all three values since channel maxes out at 15 (4 bits), note at 127 and velocity at 127 (7 bits).

Anyway... welcome to Mozaic scripting. It's a lot of fun when you make something... and it works. When it doesn't there's a lot of help available without bothering @brambos.