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

wim

Wow. That is sad.

This prompted me to check if my review is still active. It's not. I hate that.
Fixing ... another 5 stars on the US App Store at least. But ... Mozaic is at 100% 5-star there already.

hes

@wim said:
OK, Strings are out. I can live with that. I respect @brambos sticking to his vision. I feel bad for those that take it personally when his vision doesn't fit theirs, when it does so much.

@brambos - how about something like this possibly very simple enhancement?

NumToChar <array>: When used in a label, returns the UTF-8 character equivalent of each integer in the array.

No need for changing storage, string manipulation, manipulation or anything. The user stores integers in whatever way works for them. I don't know if returning a null character or some dummy character, or throwing an error is the best way to handle non-convertible characters, but the basic idea seems like it might be very-low impact to the language.

I like that idea, seems like it could be very useful. We already have string concatenation for labels and log lines, this could simply be a single function that operates on an integer, yielding a character that can be concatenated in labels and logs. I'm no expert in constructing interpreters, but I can't see how this would be difficult to add to existing Mozaic framework.

Nobody is saying brambos hasn't delivered what he promised. Mozaic is already an excellent tool. However, the explanation that Mozaic is simply "done" seems really odd to me. It's a rare piece of software (and/or a dying piece of software) that doesn't grow organically over time, depending on the needs/desires of its users. Of course, developer economics/time/effort/complexity always factor in. But the suggestion by Wim seems like an easily implemented change that would address a lot of people's gripes.

wim

Syntax ideas:

• NumToChar <variable>, <start> [, <length>]
• NumToChar <variable>, <start> [, <end>]
• Or, maybe a different enclosure in Log or Label: Log {Hello }, #myVar[0 ... 4]#, {!}

Anyway - just some loose thoughts. ✌🏼
And for the record, I have no idea if this would be an "easy" request or not.

McD

@hes said:work.
The explanation that Mozaic is simply "done" seems really odd to me.

He's saying he believes adding this feature will de-stablize the application and
not serve the interests of it's users. If we proposed a useful feature he believed would
add extra value I'm sure he'd consider putting in more effort but he gets to
make those decisions of what to add and what to avoid. He's shown excellent
judgement over a huge collection of applications on many platforms and not
lost his focus on making high quality solutions that sell and deliver value at a fair price.

We should try to gently influence him to consider adding @_Ki's "indexed label lists"
because that would save a lot of if-then-elseif table madness for each label option and probably still be stable so everyone wins. We write more scripts and prove the value to users and more purchase the app to run them. Win for @brambos, scripters and Mozaic MIDI FX users.

Don't attack the source of the potential solution.

wim

nvm. deleted.

McD

@wim said:
nvm. deleted.

I should try that once in a while... I think it's called prudence.

GovernorSilver

I'll drop in a 5-star review if needed. I admire the incredible patience of some stellar folk here.

Tim6502

@brambos said:
I never even imagined anyone would write a script of more than 100 lines

This is the disconnect. I think that Mozaic has wildly outgrown its original vision. It has become too useful and immediately usable to be just set aside.

Which makes the discussed limitations - when you hit them - all the more jarring.

Jocphone

I also asked for string concatenation some months ago. @brambos explained the position with regard to Mozaic and I fully respect that. That's as far as it goes.

@brambos has every right to define the limits of the application. If someone wants something that doesn't fit within the spec of an existing app they can find something else or learn to write their own.

Tim6502

@wim said:
Syntax ideas:

• NumToChar <variable>, <start> [, <length>]
• NumToChar <variable>, <start> [, <end>]
• Or, maybe a different enclosure in Log or Label: Log {Hello }, #myVar[0 ... 4]#, {!}

Anyway - just some loose thoughts. ✌🏼
And for the record, I have no idea if this would be an "easy" request or not.

If that seems too much: remember that we do have NoteName <note> [,<showoctave>] - limited to Log or Label functions.
An even more minimal proposal could be an analogous: Chr <intexpr> which would render a single character in the same context. Even if <intexpr> were just mapped to an ASCII character from 0 to 127 (extra bonus: Unicode), it could help reduce combinatorial blowups in labeling.

_ki

@Tim6502 In many of my scripts i already make use of the NoteName function to dynamically output the letters A-G:

@OnLoad
  ShowLayout 2
  ABCDEFG   = [9,11,0,2,4,5,7]

  for i = 0 to 15
    row = 1 + (i>7)
    id  = i%8
    if (id < 7)
      LabelPad i, {Pad },(NoteName ABCDEFG[id],NO),{     },{Row },row
    endif
  endfor
@End

.

I also added this snippet to the Mozaic tips and tricks wiki page

Tim6502

@_ki said:
@Tim6502 In many of my scripts i already make use of the NoteName function to dynamically output the letters A-G:

Cool trick. Though I think it also points out how pathetic the situation is: even though you can programmatically output letters A-F and numbers 0-9, you still cannot combine both and thus compose, say, hex numbers.
Well, you could, using 'only' 4 cases to print one hex byte and more generally using 4^N cases to print N hex bytes into a label. While this may be a fun challenge to solve once, as a language feature it is simply pathetic.

IMHO a variant of Chr (originally Chr$) from BASIC per the existing NoteName feature would not require any fundamental change in Mozaic to implement.

The only things on my wishlist after that would be to allow bigger scripts (and also longer lines). If this is limited by the editor, perhaps the script could be imported as a file - this had been talked about before. Whenever the imported script does not fit the edit limitations, editing in Mozaic itself can just be disabled.

_ki

@Tim6502 In Mutator i output hex-bytes on some of the knobs - like you said with 4 cases

.

Regarding script length - i assume its now around 128kb. Using over 3000 lines makes the internal editor stumble, but you still can paste-all from a texteditor and upload without problems. As i know i‘m way above the intended script length, so i don‘t consider this a bug.

Having lots of Mozaic instances with several of these large scripts may even break the per-plugin total memory limit - done that And it‘s nothing Bram could change.

Line length is already fairly long. I only need long lines for building the labels and in 90% of the cases the current limit is enough.

.

Bram already raised the line-length, the number of vars and events, i suspect in these cases we are already the limits imposed by the underlying system.

.

„Chr xxx“ is a nice proposal, only one function, allowed in string parameter lists, no side effect on other functions and a short name - i would love if this also „inofficially“ supported unicode. Long time ago i discussed several minor bugs regarding Unicode with Bram - he could have removed all uncode support at that time, but luckily he left it in - but never highlighted or mentioned this feature in the manual or his own examples. We wouldn‘t have icons on the pads, knobs or logs etc...

Tim6502

@_ki said:
Regarding script length - i assume its now around 128kb. ...
Having lots of Mozaic instances with several of these large scripts may even break the per-plugin total memory limit - done that

That does seem surprising. Off the cuff, I'd surmise the variables would take up to 1-2MB and similarly the program. Seems the per-instance overhead should not be more than 10MB and generally 30 instances possible.
I did hit the script size limit with the OB-Xd presets, which are ~500KB combined. Obviously that was generated, not hand-edited, but Mozaic is just too useful a tool.

I only need long lines for building the labels and in 90% of the cases the current limit is enough.

Still, it appears you hit the limit then. I suppose that in Bram's thinking this does represent less than 10% of the users - but then those users may be responsible for creating over 90% of the really cool scripts out there.

espiegel123

@Tim6502 said:

snip snip snip

Cool trick. Though I think it also points out how pathetic the situation is: even though you can programmatically output letters A-F and numbers 0-9, you still cannot combine both and thus compose, say, hex numbers.

Snip snip snip

IMO, it is pretty rude to use the word “pathetic” for not implementing something you would find helpful. While I would find some string-related features useful, I also repeat Bram’s decision and HIS KNOWLEDGE OF HIS CODE vis-a-vis the implications.

Mozaic is amazingly useful as it is. It seems pretty rude to be so dismissive cuz it doesn’t do everything you want it to.

wim

@Tim6502 said:

@_ki said:
Regarding script length - i assume its now around 128kb. ...
Having lots of Mozaic instances with several of these large scripts may even break the per-plugin total memory limit - done that

That does seem surprising. Off the cuff, I'd surmise the variables would take up to 1-2MB and similarly the program. Seems the per-instance overhead should not be more than 10MB and generally 30 instances possible.
I did hit the script size limit with the OB-Xd presets, which are ~500KB combined. Obviously that was generated, not hand-edited, but Mozaic is just too useful a tool.

If I remember correctly, the problem is the iOS text editor component for some reason takes up a huge amount of memory per line and bogs down. At one point he added "lazy loading" so that scripts only load into the editor when being edited, to reduce the AU memory footprint. I can understand not wanting to write a custom editor, which would be almost as much effort as the app itself, just to get longer scripts than the thing was intended for in the first place.

I only need long lines for building the labels and in 90% of the cases the current limit is enough.

Still, it appears you hit the limit then. I suppose that in Bram's thinking this does represent less than 10% of the users - but then those users may be responsible for creating over 90% of the really cool scripts out there.

The Lemur style power user was never what this was targeted at. Because it is so good at what it does, it attracts power users and those power users want it to become what they think it should be. They can't drop it for something else ... because there isn't anything else. It isn't the developer's fault if people try to use it for things it was never intended to do.

Also, c'mon, it's a $7.99 app, not Visual Studio 2019. And as far as % of users ... I think the other 99% of Bram's customers would rather have him focus on cool audio apps that don't require any scripting.

hes

@wim said:
If I remember correctly, the problem is the iOS text editor component for some reason takes up a huge amount of memory per line and bogs down. At one point he added "lazy loading" so that scripts only load into the editor when being edited, to reduce the AU memory footprint. I can understand not wanting to write a custom editor, which would be almost as much effort as the app itself, just to get longer scripts than the thing was intended for in the first place.

First, let me say I respect Bram's right to do whatever he wants.

But the editing issue could be pretty easily fixed by having Mozaic save its code to text files in a 'Mozaic' folder accessible in the Files app, and to optionally open/import the code from that file rather than the binary file that Mozaic now uses.

That would create additional flexibility, e.g, making it simple for people to use github to collaborate on Mozaic projects (using an ios github client app like Working Copy).

wim

Access to the file system would be wonderful for many things. I don't expect it to happen, but it would open up a world of possibilities.

hes

@wim said:
Access to the file system would be wonderful for many things. I don't expect it to happen, but it would open up a world of possibilities.

Yes. [But what I suggested is far from a general purpose access-to-file-system functionality, which you can't have on ios, and I'm not even suggesting generalized access for reading or writing files to a Mozaic directory. Just that the Mozaic app could save and load/import text to/from files in its own folder.]

And I understand Bram's position, I think, which I assume is mostly an economic one. I expect (rather than just hating to work on Mozaic app) that there aren't enough sales to justify much development time. However, it seems there's a growing base of Mozaic users who don't do much programming at all, just grab Mozaic and load an app from Patchstorage.com. If the Mozaic app made it easier for the "coding people" to develop better apps, then I expect the Mozaic user base would expand even more, adding lots more users who are merely making use of Mozaic apps that others have coded.

I have no idea of the purchaser/user numbers, though, or how those numbers compare to those of Brambos' more typical ios music apps (all of which seem to be excellent).

EDIT: Also, just as a marketing thing, maybe Brambos should consider promoting Mozaic less as a "roll your own solution" midi coding app, and more as a "Gives you access to scores of user-created apps" type of thing. Along with, maybe, profiles or highlights or youtube links for some of the more impressive Mozaic apps.

wim

I can't speak for anyone, but I don't get the impression economics are the driving factor in whether feature requests are adopted or not. He knows what he feels are appropriate additions and which aren't.

Your last comment is a key point of my recently updated review pointing out that even if people can't write a lick of code, it's like getting an unending stream of cool and free midi apps.

Tim6502

@espiegel123 said:
IMO, it is pretty rude to use the word “pathetic” for not implementing something you would find helpful.
...
I also repeat Bram’s decision and HIS KNOWLEDGE OF HIS CODE vis-a-vis the implications.

The pathos is in the frustration when attempting to code in that one particular corner of the language without "helpful assistance". Other folks have given more detailed descriptions on this earlier in the thread.
I am not imputing the excellence and utility of Mozaic or the genius of its creator. Perhaps the problem is it's just too good. There is no comparable excitement for, say, StreamByter.

@brambos said:
If it would be a matter of adding a function or three I wouldn't hesitate ...

There already are language features in this space: NoteName <note> [,<showoctave>], RootNoteName, and ScaleName [<scalenum>] so utility and a path to implementability appear to be acknowledged.
One would surmise that - mutatis mutandis - something like Chr <number> to inject a one-character string into the same scope would be possible and useful. If need be, limiting the number to between 0 and 127, this has a similar magnitude as NoteName.

Just would like to see the vision of this wonderful Mozaic tool expanded, even if one little step at a time.

mbncp

Nice, found the FR section 🤓

It would be great to have different color of the icon, with 30+ Mozaic instances it’s difficult to find what you need especially that AUM puts them in alphanum order 😤
Not sure this would work on iOS

Also it’s funny that nobody asked but string arrays with a few string related functions would be welcomed (in French we say « enfoncer le clou » ) ☺️

wim

@mbncp said:
Nice, found the FR section 🤓

It would be great to have different color of the icon, with 30+ Mozaic instances it’s difficult to find what you need especially that AUM puts them in alphanum order 😤
Not sure this would work on iOS

I don't think that is possible on iOS.

There is a thing called the short name that AUM displays below the icon. It's only six all-caps characters, so not super useful, but can be used (by altering the script) to differentiate instances.

Also it’s funny that nobody asked but string arrays with a few string related functions would be welcomed (in French we say « enfoncer le clou » ) ☺️

OK, you're joking right? If not, just scroll up a few pages if you dare.

mbncp

@wim said:

There is a thing called the short name that AUM displays below the icon. It's only six all-caps characters, so not super useful, but can be used (by altering the script) to differentiate instances.

Yes that’s what I do, but it has its limitations, and in AUM you still have to set the name again in the window. Well no big deal.
But my sysex monitoring script would really love string concatenation. 😢

hes

@Tim6502 said:
Just would like to see the vision of this wonderful Mozaic tool expanded, even if one little step at a time.

Agreed. Organic growth is the pathway of software nirvana.

SpartanClownTide

I'd rather @brambos consider a Mozaic 2 for MIDI 2.0 than extend the original remit. I know it's early days and adoption isn't going to happen over night but I'd love to get my head around v2.0 with Mozaic script.

brambos

[deleted - Never mind - not worth it.]

wim

Hi @brambos - I have a small feature suggestion. Not essential, but would help streamline code in some cases and open up some doors. It would be great if there could be @OnKnobTouch and @OnKnobRelease events.

This would make it possible to use taps, etc. on knobs, as well as making it possible to defer actions and other knob updates while doing adjustments. Often there are a lot more UI updates than necessary when going through a lot of values. It's sometimes nice to be able to mess with a knob such as one sending program changes and not have a bunch of unwanted messages going out until the adjustment is done.

Just a thought.

McD

@wim said:
Hi @brambos - I have a small feature suggestion. Not essential, but would help streamline code in some cases and open up some doors. It would be great if there could be @OnKnobTouch and @OnKnobRelease events.

This would make it possible to use taps, etc. on knobs, as well as making it possible to defer actions and other knob updates while doing adjustments. Often there are a lot more UI updates than necessary when going through a lot of values. It's sometimes nice to be able to mess with a knob such as one sending program changes and not have a bunch of unwanted messages going out until the adjustment is done.

Just a thought.

I like that. Knobs right now created a lot of events while you're just trying to dial in a new value but you're really creating dozens of events that get activated in a fraction of a second. That's got to consume a lot of resources and potentially cause problems. Like a burst of events when you're just moving a knob from 0 to 127. I'm making a lot of assumptions how knobs work.

I'd also like to be able to tap on the knobs in my GUI's and not have to choose a GUI option with PAD's.
I use the 22 knob view most of the time but learned to "shift" over to the PAD view to display the contents of a sequence from 1 to 16. I mostly use PAD's to get more text on the screen since I assume users don't vent know how to see Logged text messages.

TheOriginalPaulB

@McD said:

We should try to gently influence him to consider adding @_Ki's "indexed label lists"
because that would save a lot of if-then-elseif table madness for each label option and probably still be stable so everyone wins. We write more scripts and prove the value to users and more purchase the app to run them. Win for @brambos, scripters and Mozaic MIDI FX users.

On reflection, Ki’s scheme would be overkill. Given that the majority of controls are not visible in any one layout, but are still referenceable, all that would be needed would be two functions, GetKnobLabel num and GetPadLabel num. These would only be useable in Log and Label calls in the same way as NoteName, etc., so they would use mechanisms that are already in place and would not affect the rest of the Mozaic engine. That way, building a dynamic compound label would be as easy as

LabelPad 0, (GetKnobLabel 20), { : }, (GetKnobLabel 21)

assuming one has already assigned labels to Knobs 20 and 21.

Simples...