Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Comments
I’ve just had to write an if cascade to label a pad with the possible combinations of 4 knobs having 4 options each. That’s 256 options, plus LabelPad statements, plus the intermediate if clauses (444*4 compounds as you go), plus a whole bunch of endifs. It’s about 600 lines of code. To label one button. There are supposed to be others. Changing knob function based on pad selection is a useful tactic, but you need to be able to display the settings when other pads are selected. I’ve put this project on hold, as this much code to label a button is ridiculous. I couldn’t post my example here, it was rejected as being too long, but I did send the code to @brambos .
I did see it, and indeed it's a lot of code. But I stand by my decision to not support string types and manipulation in Mozaic beyond the constant-labels that are currently there.
Every script language has an intended purpose where its strengths lie. Obviously for Mozaic that's handling MIDI data and the various conditional wizardry that's needed for it.
String manipulation would introduce the need for a massive number of new and complex functions and data types that do not directly serve the intended purpose of Mozaic (and once you add one or two, people will demand all the others too). I see how it could be useful for intricate UI solutions, but it's still not worth the additional effort in the grand scheme of things as it would for me at least double the complexity of the existing engine.
@brambos
Ok - last try, i promise
Here a further refined idea on how to offer a solution to the if-cascade-to-set-labels problem:
No new data types, no mem requirement, no memory allocations or memory copy actions.
.
Lets imagine Mozaic manages an new array of 128 or 256 ‚string constant‘ references into the source. With that i mean that the interpreter does not copy the strings from the source, but instead only stores null (not set) or an offset into the source-code. The string-constant-array is of fixed size, allocated at plugin initialization. If upload is pressed, everything is re-initialized to null or another value indicating that an array entry its not set.
The
SetStringConstants idx, {a},{list},{of},{strings}command would set these references, starting at idx. Having the idx parameter allows to split up the initialization onto several lines. The interpreter only copies the offsets to the opening ‚{‚ as a reference to the string into the string-constant-array, not the strings themself. Done this way, there is no chance of memory leaks as nothing needs to be allocated.The
StringConstant idxfunction can only be called where the other exisiting string-functions like GetNoteName, RootNoteName, ScaleName are allowed. The interpreter looks up the string-constant-array and if not null, retrieves the string from the stored offset and add it to the output. If the reference is null, or the idx less than 0 or greater than the size of the string-constant array, nothing is added to the output..
It would be better if the ‚StringConstant* function had a shorter name, as in several cases i need to use about 10 of them in a single line and with a long name, one would run into ‚line length‘ problems. Maybe name them ‚SetStrings‘ and ‚String idx‘ which is a bit shorter
All we’d need is storage and retrieval, you could draw your line in the sand there. Without that, many utilities will not get made. You may as well not have labels at all if it’s that much effort to use them flexibly. I’m only on my 3rd Mozaic project and I feel like I’ve outgrown it already. I’m sorry to say this, but if I’d known it had such a low ceiling 3 weeks ago I probably wouldn’t have bought it.
I also hope that all is well and you are you are silently programming something completly different with which you will surprise us once again
I also understand that Mozaic is basically ‚done‘ and new features won‘t bring new customers, but instead offer the chance for side-effects to creep in... So i have mixed feeling about my above request. Nevetheless, it would be so great if these functions were there. They not only simplify our scripting, but i also have some idea in my back hand, which will only be do-able if they exist. But perhaps these ideas reach too far...
What's a low ceiling for some, is a nigh unattainable ceiling for others. And I reckon it's almost impossible to create a tool that is accessible and instantly-gratifying to absolute beginners and deep enough for people with years of low-level coding experience.
For advanced users XCode offers multiple other languages (instead of a script). Mozaic was made as a quick and relatively easy solution for exotic MIDI problems that would never be solved by general purpose MIDI plugins (people kept asking me to add plugins to Rozeta for really obscure one-off use cases... So that's the need that Mozaic tries to address).
I never even imagined anyone would write a script of more than 100 lines
It’s not the stuff under the hood that Mozaiic lacks. I haven’t once felt the need for low level functionality. It’s the UI that’s crippled. Without the ability to give adequate visual feedback to the user, (barring writing thousands of lines of code), applications become obscure and difficult to use. I’ll carry on writing scripts for my own purposes, my current project generates 4 part fugues, either on its own or based on a theme played by the user, but because the UI will be too opaque, I will not be considering sharing it on PatchStorage.
@TheOriginalPaulB You probably wouldn’t have liked coding for StreamByter, which initially was more like assembler with its 3 char per instruction, one letter variable names, everything capitalized, no expressions, no logging etc. Got better and offered more language features in the end, but Mozaics more high level approach convinced very quickly as it’s easier to try things out and the scripts are more compact and readable.
In my opinion Mozaic is the best and most advanced midi scripting option we have on IOS and its practically bug-free, everything just works as stated in its excellent manual.
Mozaic is capable of performing many different and even complex midi tasks, but one has to cope with the language constructs that are available. You gotta do some maneuvers, but you can emulate data structures and linked lists even with linear one dimensional arrays. I understand that this kind of juggling isn’t everybodies cup of tea.
.
I still enjoy scripting in Mozaic, even though i managed to hit the barriers of what‘s capable of several times now and even in different dimensions (cpu, event-max, var-max, script-length-max, if-cascade max ...)
@_ki I’ve coded in a lot of languages, from assemby upwards, so it’s basically horses for courses. Streambyter doesn’t even pretend to have a UI, so this issue wouldn’t arise, as I wouldn’t use it for tasks that require one. Mozaic has a lot of possibilities and most of the time a little ingenuity can overcome its limitations, but you yourself have acknowledged that there’s no way to build dynamic labels other than if cascades. Writing thousands of lines of highly repetitive code just to support the UI is not juggling, it’s tilting at windmills and really not worth the time and effort.
Agreed, Mozaic's UI capabilities weren't really meant for that. Just for adding basic labels to knobs and controls to indicate their purpose. All script tools have grey areas where you start straying outside the realm of intended use cases, this is clearly one of Mozaic's
I think I said this during the good old Flow days;
If Mozaic supported appending to labels such as ”LabelKnobAppend”/”LabelKnob+” we’d need to write a lot less code for a lot of UI purposes. It clearly doesn’t solve all cases, but it would address most ”string concatenation” needs I’ve seen discussed in this forum over the last year+ or so.
@Brambos and @TheOriginalPaulB I just had a look at your example for the extreme long pad label setting if-cascade you uploaded to PatchStorage
With my two proposed functions all the 681 lines of code needed to just set a pad label would collapse into just two lines:
The second line wouldn‘t be that long, if a) your variable name was shorter and b) the ‚GetConstant‘ function name would be shorter, like when using ‚String‘ and ‚SetString‘ as new names
Its safe to call the SetStrings function not only in the OnLoad, but even in the knob labeling event as no new mem is allocated or things need to be copied - its just that the references could change during runtime.
.
Your case was 4x4x4x4 = 256 variants, but the needed if/elseif/endif add up to over 400 lines.
As said, i have use-cases ideas where i would need about 10 of these (String xx) in a single LabelPad line, its impossible to unroll that to an if-cascade due to number of possibilities.
And you probbably didn’t expect the multi-line pad label UIs when you though about that labels:
All done with the the cost of extensive if-cascading... and we could do even more crazy things if we had the String constants
.
Okay, okay - i admit, some of these (HostClock & NoteStatistics) wouldn‘t really profit from the feature-request... but i wanted to show the variety. And not to forget that others also have done cool UIs with icons and stuff in the labels, which probably also wasn‘t in the intended scope of the ‚LabelPad‘ or ‚LabelKnob‘ functionality
All I’d have needed was
Part1str = {S.}
Part2str = {A.}
Part3str = {T.}
Part4str = {B}
// Elsewhere in the code.
LabelPad pad, {Part Registers (}, Part1str, Part2str, Part3str, Part4str, {)}
I really don’t understand why brambos is so insistent on hamstringing Mozaic for the sake of not implementing this one feature. It would really improve the user experience.
@Peblin Cool, i see a different idea
But appending wouldn‘t really help in case of TheOriginalPaulB problem, instead of one 256 variant if-cascade, you would reduce that to four if-cascades with 4 variants each. With the if‘s thats still about 40 lines of code - versus the two lines i came up with that get rid of the cascades at all. With my approach you only need an if/else/endif, if the stucture of the label output changes, but not for different contents in the same order.
@TheOriginalPaulB Strings as datatypes are completly out of the scope of Mozaic - adding them is like opening pandorras box. Internally there is only one data type - a number. And anything else would require a complete rewrite and new software architecture - including all needed testing and so on.
Don‘t even think about having strings or string constants that way in Mozaic. Its simply not possible.
.
My proposed feature offers the same result, but doesn‘t need strings to be implemented at all, or any change of data types or expressions.
That’s bollocks. Mozaic can read and display string constants, so there is some capability for handling strings already. All Mozaic variables are arrays, strings are a special form of array. All you’d need internally is a flag to denote that the array is a string, (perhaps its length would do for this, being useful in assignments to other variables, with 0 signifying non string variables), that would also tell the mozaic engine to interpret ASCII values, storing letters as ints and translating back to letters on output in Log or LabelXxx calls.
Your way would confuse beginners, my way is completely transparent.
Don‘t get me wrong, i don’t want to start a fight or endless argument, i hope this will be my last post concerning this topic. I start to fear no-one else understands what i‘m talking about, and that my proposed feature was very carefully designed in that specific way and why it did it that way...
.
I had lots of PM discussions about about Mozaic internals and especially strings back and forth with Brambos last year.
.
Strings are only allowed as parameters in limited number of functions, like LabelPad, LabelKnob etc. Never in expression or variable assignement.
And then there are just some few functions that internally produce strings like ScaleName, NoteName etc - beeing only allowed as parameters to the mentioned functions allowing string paramaters.
.
Your idea requires a change of the innards of how Mozaics interpreter work - it‘s not just an extension that doesn‘t touch other parts of the interpreter engine. Your proposal adds variable-types to language without such concept and also new type of assigment. And if there is an assignment, people want to also have string operations like concatentation, etc. Pandoras box
.
I fully understand that ‚my way would confuse beginners‘, but i fear that‘s the only bridge we could get as it tries to minimizes the changes needed to be added to the interpreter and it fits with the concept like the existing RootName, ScaleName etc functions.
.
But with all this ranting about this single feature, which wasn’t indended at all for Mozaic i supect Bram is already annoyed. So it‘s back to long if-cascades for us script slaves
I did see @j_liljedahl write that we wouldn't make AUM a slave to another MIDI clock since it's a DAW and DAW's have to own their clock.
But after months of the same question re-surfacing he wrote he'd give it a shot but he's
not making any promises for timing quality.
I guess, never say never.
@_ki's scheme of the scripter providing a list of labels and then using list item numbers for labeling would be very useful as a "good enough" enhancement. I wouldn't expect more than just the display of the text I created in the list.
I was a professional software engineer for 18 years, 10 of those in an odd combination of embedded systems and user interfaces. I know exactly what you’re talking about.
I suspect brambos says whatever helps his case.
So he already has a way of handling them.
We already have concatenation, where strings are passed to the Label and Log functions. No need for it elsewhere.
Your way is a kludge, but neither your method nor mine will get implemented. I’ve seen this before. brambos is no longer listening, Mozaic will remain as it is.
I don’t care whether he’s annoyed or not, his implementation is flawed and he can’t admit it.
Anyway, I agree with you on one thing. We’re done here.
Never say never.
The implementation is extremely solid and powerful as is. Still... nice to have
this one extra feature and it might stimulate another round of users to invest.
Maybe split it into a $2 runtime app pre-loaded with scripts or the automation of
PatchStorage installs. And a new "Pro" developer's app to justify the extra work implementing this extra feature and it's anticipated support requirements.
I'm in the middle of a 5 hour process of writing an "if" cascade to put a series of on/off lights (in the form of white/black square emojis) into the knobs header, for the view where the "knobs" are sliders. Having spent so many hours with Mozaic, I'm hoping that Mozaic becomes a cultural phenomenon, as is.
I'm not such an experienced programmer; I've learned the most by inventing apps with Mozaic. Sometimes the limitations have been fun. Not for my current project, but fairly often. Slippery slope aside, I do think some string functionality would be nice to have.
I would like to see a sequel to Mozaic, maybe like three years from now. We'd then have two options for complexity, without splintering the community early on. It could have "Make your own layouts" and features like that. Very few people have the knowledge or time required to create such a thing, and maybe those few people won't have the desire. But it's easy to imagine pads and knobs with attributes for visibility, size, and position, being placed wherever you want. Or multiple XY pads, or different background colors. I support the quest to add simple features to Mozaic, but I would also love to see something more powerful in the future. @brambos Have you ever thought about it? Helping Mozaic to outgrow its intended purpose? Mozaic hats, Mozaic water bottles, Mozaic toilet seat covers, sports games at the Mozaic Center, roller coasters at Mozaic Land.
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?
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 haven’t taken it personally. I’m just pissed off that it only took me 3 projects to run up against such a needless showstopper when the rest of the package had such potential.
I’ve accepted he isn’t going to do anything about it and have adjusted my expectations of Mozaic’s usefulness accordingly.
He isn’t going to bother to do this, either, just wait and see.
Yeh, you're not bitter at all.
It's totally up to @brambos if he takes that suggestion or not. It won't bother me in the least. It ain't my product.
smooch
✌🏼
How is it a "flaw" and a "needless showstopper"? Sorry, but that's a little unfair.
Mozaic does exactly what I designed it to do: MIDI handling with a minimally adjustable UI layer and a syntax that's conceptually easy enough to grasp for literally everyone. Nowhere have I promised a fully programmable UI design tool or C-level language features. That has been quite clear from the start.
I have also explained that adding string handling is not trivial. You may dismiss this notion, but I am convinced that it would complicate my engine massively. And for what? Just for doing labels in the UI, which is barely a secondary use case for Mozaic.
I apologize if this disappoints you, but I have to make decisions - I can't magically make anything happen without much effort. Some things are simply too much work, too much risk and too much hassle with limited added benefits for the core target use cases. Mozaic is nice and stable and bug-free now, I'd like to keep it that way. Adding string handling would be like half a year of added work, lots of beta-testing and potentially lots of new bugs, crashing and other undesirable side-effects.
If it would be a matter of adding a function or three I wouldn't hesitate (like adding Sysex which wasn't originally there, but many people saw use for it), but it's quite a bit more involved than that, unfortunately
Just for the record ...
Features I can think of off the top of my head that have been added in response to user suggestions:
ColorPadsScaleName [<scalenum>]SystemTimeGetXYMorphValueA clear explanation (not a defense) has always been offered when he doesn't want to do something. Every known bug is always fixed. Best of breed developer approach IMO.
Also, leaving a 1-star review? Seriously..? 1 star usually means an app simply doesn't work, is made to scam you or has no redeeming qualities whatsoever.