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

Peblin

@brambos said:

@wim said:

@gusgranite said:
@wim it’s weird. I cannot seem to save your MIDI CC patch. I download it, open in Mozaic, I see it load in the standalone instance, but when I save it, close the standalone, and open the an AU instance of Mozaic it is gone? I can see other patches I have downloaded OK. Strange.

No need to save it in the standalone app. Maybe that’s the current bug where saving when not viewing the code loses the code. Can you try not saving and see if that helps? I’ll try some things here too...

No, I just tried. Works as expected over here.

And the update with the bugfix is already live. There are no known bugs in the current version

I actually experience something vaguely related - when downloading the PulseSequencer patch from patchstorage, it doesn't replace the old PulseSequencer 0.1.
I've deleted PulseSequencer 0.1 from Mozaic (left-swipe), then "download" it using Safari->Open in. When I then open PulseSequencer in the standalone it's the old 0.1 (that I deleted!) that opens and the new 0.3 is nowhere to be seen.

Edit: PulseSequencer is not the only patch that has behaved like this - but it might be some kind of Safari browser caching issue rather than bugs in Mozaic.

wim

I eventually got it to show up in the load dialog of the standalone. But it took shutting down the standalone, shutting down Mozaic in AudioBus, shutting down AudioBus, and ... lastly, clearing RAM to get it to show up. It wasn’t until the ram clear that it would appear.

I suspected Safari caching too, but this was a new patch, not an update over an older version.

brambos

Ugh.. the joys of file handling on iOS. I'll look into it. But strangely enough it worked for me the first time I tried. I'll see what happens when juggling with multiple versions of the same file.

gusgranite

Also when I select ‘open in’ it automatically opens the standalone. I don’t have a choice. Good to know you don’t have to save. I only started hitting save when it wasn’t showing up.

gusgranite

It worked this time. The only difference was I didn’t have any host open. Hmm

brambos

@gusgranite said:
Also when I select ‘open in’ it automatically opens the standalone. I don’t have a choice. Good to know you don’t have to save. I only started hitting save when it wasn’t showing up.

Yeah, that's as it should be. You can't "Open in..." directly into an AU plugin. You always have to import it into the standalone, which then needs to pass it on to the plugin (which lives in another isolated sandbox, unaware of what happens in the standalone app). Handling files on iOS is a never-ending pain.

gusgranite

@brambos thx

@wim I can finally put a bit of random into Zeeon! (Even if I can’t get it to work on the Zeeon mod matrix just yet). Awesome!

wim

If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

brambos

@gusgranite said:
It worked this time. The only difference was I didn’t have any host open. Hmm

Oh. that's an interesting observation! Perhaps the app->plugin file synchronization doesn't happen if the plugin is already loaded and active elsewhere.

Thanks, this could be a helpful hint!

brambos

@wim said:
If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

That space shouldn't make a difference. If so, that's a bug.

Edit: just tried, the space isn't necessary there. Works either way

wim

@brambos said:

@wim said:
If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

That space shouldn't make a difference. If so, that's a bug. I'll fix that asap.

It’s odd because it had to have worked hundreds of times, but not when I just tried it out. Very strange things going on tonight. Sunspots maybe?

wim

@gusgranite said:
@brambos thx

@wim I can finally put a bit of random into Zeeon! (Even if I can’t get it to work on the Zeeon mod matrix just yet). Awesome!

Glad it may be of use to somebody! All these scripts I write, then can’t think of any use for. 😂

brambos

@wim said:

@brambos said:

@wim said:
If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

That space shouldn't make a difference. If so, that's a bug. I'll fix that asap.

It’s odd because it had to have worked hundreds of times, but not when I just tried it out. Very strange things going on tonight. Sunspots maybe?

No, I just tried, no space needed there. Just for aesthetic purposes perhaps

wim

@brambos said:

@wim said:

@brambos said:

@wim said:
If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

That space shouldn't make a difference. If so, that's a bug. I'll fix that asap.

It’s odd because it had to have worked hundreds of times, but not when I just tried it out. Very strange things going on tonight. Sunspots maybe?

No, I just tried, no space needed there. Just for aesthetic purposes perhaps

And yet, it was working, then it wasn’t working for several tries, I added the space, and it started working again. Beats me!

brambos

@wim said:

@brambos said:

@wim said:

@brambos said:

@wim said:
If you just downloaded that one and the view switching is messed up, re-download and reload. There was a space missing in an array assignment. I don’t know how that crept in since it worked fine just prior to uploading. The line layouts[0] = [1,2] should be layouts[0] = [1, 2]

That space shouldn't make a difference. If so, that's a bug. I'll fix that asap.

It’s odd because it had to have worked hundreds of times, but not when I just tried it out. Very strange things going on tonight. Sunspots maybe?

No, I just tried, no space needed there. Just for aesthetic purposes perhaps

And yet, it was working, then it wasn’t working for several tries, I added the space, and it started working again. Beats me!

I tried this:

layout[0] = [1,2]
log layout[0]
log layout[1]
log layout[2]

And it gives me the expected outcome ( 1 , 2 , 0 ). Now I'm confused...

wim

@brambos said:
I tried this:

layout[0] = [1,2]
log layout[0]
log layout[1]
log layout[2]

And it gives me the expected outcome ( 1 , 2 , 0 ). Now I'm confused...

Why is that expected? Shouldn’t log layout[2] throw an error since it’s Unassigned?

brambos

@wim said:

@brambos said:
I tried this:

layout[0] = [1,2]
log layout[0]
log layout[1]
log layout[2]

And it gives me the expected outcome ( 1 , 2 , 0 ). Now I'm confused...

Why is that expected? Shouldn’t log layout[2] through an error since it’s Unassigned?

No, because if you assign a value to any cell of 'layout' the entire (array)variable becomes valid. In other words: validation works 'per named variable', and not per array cell.

Under water there's a pool of memory waiting to be assigned. As soon as a portion of that memory has been given a name it becomes valid. So as soon as you call 'layout[0] = [1,2]' the system knows 'layout' exists and where in memory it lives

wim

@Brambos, thinking back through the sequence of events, I think the ilayout and/or layouts variable may have become inconsistent due to all that was going on with trying to load the patch. I had the patch open and was using it in Audiobus. Then I uploaded from patchstorage.com into the standalone. I think this caused whatever weirdness I saw. I just assumed that it was due to the missing space because as soon as I uploaded the modified code it behaved like it should.

Probably just too many uncontrolled variables floating around at the time.

wim

@brambos said:

@wim said:

@brambos said:
I tried this:

layout[0] = [1,2]
log layout[0]
log layout[1]
log layout[2]

And it gives me the expected outcome ( 1 , 2 , 0 ). Now I'm confused...

Why is that expected? Shouldn’t log layout[2] through an error since it’s Unassigned?

No, because if you assign a value to any cell of 'layout' the entire (array)variable becomes valid. In other words: validation works 'per named variable', and not per array cell.

Under water there's a pool of memory waiting to be assigned. As soon as a portion of that memory has been given a name it becomes valid. So as soon as you call 'layout[0] = [1,2]' the system knows 'layout' exists and where in memory it lives

Not really. Try this:

@OnLoad
  layouts[0] = [1, 2]
  log layouts[0]
  log layouts[1]
  if Unassigned layouts[2]
    log {Layouts 2 is Unassigned}
  endif
@End

Layouts[2] is unassigned. Showing a zero is inconsistent.

brambos

@wim said:
@Brambos, thinking back through the sequence of events, I think the ilayout and/or layouts variable may have become inconsistent due to all that was going on with trying to load the patch. I had the patch open and was using it in Audiobus. Then I uploaded from patchstorage.com into the standalone. I think this caused whatever weirdness I saw. I just assumed that it was due to the missing space because as soon as I uploaded the modified code it behaved like it should.

Probably just too many uncontrolled variables floating around at the time.

I suspect that's why support always tells everyone "Have you already tried a restart"?

Anyway.. I'm going to follow up on @gusgranite 's lead that something odd may be happening when another host is already running the plugin. It's possible that this interferes with file synchronization (or maybe even blocking file access to the sandbox?).

wim

@wim said:

No, because if you assign a value to any cell of 'layout' the entire (array)variable becomes valid. In other words: validation works 'per named variable', and not per array cell.

If that were true (or if you make it true 😳) then half my scripts wouldn’t function. I use if Unassigned array[#] all over the place!

brambos

@wim said:

@wim said:

No, because if you assign a value to any cell of 'layout' the entire (array)variable becomes valid. In other words: validation works 'per named variable', and not per array cell.

If that were true (or if you make it true 😳) then half my scripts wouldn’t function. I use if Unassigned array[#] all over the place!

It has worked like that since the beginning, so there's probably nothing to worry about: if 'array[50]' is unassigned, then 'array' as a whole is also unassigned and both would return the same result anyway.

wim

@brambos said:
if 'array[50]' is unassigned, then 'array' as a whole is also unassigned and both would return the same result anyway.

Nope.

Script

@OnLoad
  layouts[0] = [1, 2]
  log layouts[0]
  log layouts[1]
  if Unassigned layouts[2]
    log {layouts[2] is unassigned}
  endif
  if Unassigned layouts
    log {layouts array is unassigned}
  else
    log {layouts array is assigned}
  endif
@End

Output

layouts array is assigned
layouts[2] is unassigned
2
1
[MOZAIC] Script loaded

brambos

@wim said:

@brambos said:
if 'array[50]' is unassigned, then 'array' as a whole is also unassigned and both would return the same result anyway.

Nope.

Script

@OnLoad
  layouts[0] = [1, 2]
  log layouts[0]
  log layouts[1]
  if Unassigned layouts[2]
    log {layouts[2] is unassigned}
  endif
  if Unassigned layouts
    log {layouts array is unassigned}
  else
    log {layouts array is assigned}
  endif
@End

Output

layouts array is assigned
layouts[2] is unassigned
2
1
[MOZAIC] Script loaded

Interesting! I’d say that’s a bug, but perhaps one I should make official behavior?

wim

@brambos said:
Interesting! I’d say that’s a bug, but perhaps one I should make official behavior?

I don’t see how it’s a bug. It makes total sense. So yeh, please don’t change it!

The part that doesn’t make sense is you arbitrarily assign 0 to be returned when there’s in fact no value in a cell. Why 0? Why not 666? Or pi?

If I don’t assign zero to a cell, I don’t expect to get zero back. Doesn’t make sense to me. But, I guess as long as I know that’s how it works, I can plan accordingly.

Artefact2001

An interesting synthesis ‘primer’ that Ableton have just released on the web:

https://learningsynths.ableton.com/

Why I’m posting here is there is an interesting ‘MIDI’ manipulation concept— an XY controller that manipulates synth parameters whilst advancing the note sequence on subsequent clicks/touches:

https://learningsynths.ableton.com/synth-basics/what-can-synthesizers-sound-like

Is this the 21st century version of a drum machine trigger advancing synth sequences?

brambos

@wim said:

@brambos said:
Interesting! I’d say that’s a bug, but perhaps one I should make official behavior?

I don’t see how it’s a bug. It makes total sense. So yeh, please don’t change it!

The part that doesn’t make sense is you arbitrarily assign 0 to be returned when there’s in fact no value in a cell. Why 0? Why not 666? Or pi?

If I don’t assign zero to a cell, I don’t expect to get zero back. Doesn’t make sense to me.

That's completely true in conventional programming environments. But one of my design strategies was: Mozaic should never crash or stop. So whatever happens, a valid fallback is always provided. In this case it returns a 'safe' value when no value has been provided yet.

The key reason for this is that Mozaic is a music application, and the last thing you want during a recording session or performance is a pedantic interpreter telling you that there's an error in your code, waiting for you to fix it. A small unexpected (and often unnoticeable) hickup is always preferable over a complete stop

That's also why the script will alway try to recover and keep running, in spite of 'syntax errors' etc.

Yes, there are good counter-arguments (I've considered them all), but all thing considered this seemed the philosophy that best matched what I was intending to achieve.

wim

Last thought on the arrays issue:

How would I do something like count the number of assigned cells in an array without if Unassigned array[#]? I can’t check for zero because that might be a valid number in the array.

OK, I’m done.

wim

@brambos said:

@wim said:

@brambos said:
Interesting! I’d say that’s a bug, but perhaps one I should make official behavior?

I don’t see how it’s a bug. It makes total sense. So yeh, please don’t change it!

The part that doesn’t make sense is you arbitrarily assign 0 to be returned when there’s in fact no value in a cell. Why 0? Why not 666? Or pi?

If I don’t assign zero to a cell, I don’t expect to get zero back. Doesn’t make sense to me.

That's completely true in conventional programming environments. But one of my design strategies was: Mozaic should never crash or stop. So whatever happens, a valid fallback is always provided. In this case it returns a 'safe' value when no value has been provided yet.

The key reason for this is that Mozaic is a music application, and the last thing you want during a recording session or performance is a pedantic interpreter telling you that there's an error in your code, waiting for you to fix it. A small unexpected (and often unnoticeable) hickup is always preferable over a complete stop

That's also why the script will alway keep running, in spite of 'syntax errors' etc.

Yet, you have no problem throwing an error if a variable that isn’t an array is unassigned. Sorry, that’s inconsistent. But, that’s OK by me. Just saying is all.

And yeh, I do appreciate that things generally don’t come to a halt when there’s a minor error.

brambos

@wim said:

@brambos said:

@wim said:

@brambos said:
Interesting! I’d say that’s a bug, but perhaps one I should make official behavior?

I don’t see how it’s a bug. It makes total sense. So yeh, please don’t change it!

The part that doesn’t make sense is you arbitrarily assign 0 to be returned when there’s in fact no value in a cell. Why 0? Why not 666? Or pi?

If I don’t assign zero to a cell, I don’t expect to get zero back. Doesn’t make sense to me.

That's completely true in conventional programming environments. But one of my design strategies was: Mozaic should never crash or stop. So whatever happens, a valid fallback is always provided. In this case it returns a 'safe' value when no value has been provided yet.

The key reason for this is that Mozaic is a music application, and the last thing you want during a recording session or performance is a pedantic interpreter telling you that there's an error in your code, waiting for you to fix it. A small unexpected (and often unnoticeable) hickup is always preferable over a complete stop

That's also why the script will alway keep running, in spite of 'syntax errors' etc.

Yet, you have no problem throwing an error if a variable that isn’t an array is unassigned. Sorry, that’s inconsistent. But, that’s OK by me. Just saying is all.

All variables are arrays conceptually. That's stated in the manual. There is no distinction between arrays and non-arrays and a variable can be used as both interchangeably. MyNumber simply maps to MyNumber[0]