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 Store
Audiobus is the app that makes the rest of your setup better.
I've added you as a collaborator. I'll look into making the Github "open" so I don't have to do it manually (although maybe for safety reasons this is not possible?).
I edited my post above while you were writing yours. I managed to upload into a fork, which is maybe the better way to go.
I’ll back off for now until the dust settles so I don’t make a mess. Sleep is calling anyway.💤
@wim @brambos generally you fork the repository in Github. Make changes to your own fork and then send a pull request so that the owners of the main repo can review the changes before pulling them in.
GitHub has extensive, if slightly technical help:
That's one way to do it: you create a new file or upload a file, which will create a fork. Then, you can perform a "Pull request" with that fork. After that, Bram can accept those "Pull requests". As a result, the file will be integrated into the (official, Bram owned) repository.
I think it is not possible to make a Github completely open for both safety and security reasons.
(Note also that free Github accounts have a limited number of collaborators)
A fork is what individuals in a team create from the master branch, then changes in the fork can be pulled into the master branch with a "pull request".
IMO, github is great for experienced developers, and probably too complex for "absolute beginner programmers". Isn't there something called patch storage or something like that? I think I saw a recent app use it ...
Aha.. just managed to merge Rodrigo's scripts (thanks!).
So a pull-request basically means "please check and merge with the master". What a confusing term!
I’ll look into Patchstorage.
Please hold off outting too much effort in Github for now
Yes, in the coder team world it would be Rodrigo that would be making that pull request, requesting the master admin to pull in the changes from his fork.
It is indeed confusing, until you work with it daily for a while, and then all of it makes perfect sense
They said the same about Wordperfect in the 80s
Yep, doesn’t seem like a good fit here.
I have been using GIT for 3 years and it still trips me up.
Github is used be all sorts of people for sharing and collaborating on content. Not just coding.
The fact that it has version control and issue tracking built-in makes it perfect for this kind of thing.
Don't let a little learning put you off. People can also make a gist if they don't want to fork a repo.
It's clear that I need to ponder this one a bit longer. I've just spoken with Patchstorage and they're open to adding Mozaic as a platform on their site. So that's certainly an option too.
You don't need to do any of that stuff to download a patch this is only for people who want to contribute.
i have 25 years of coding experience, using cvs and subversion - but somehow i cannot wrap my head around github too.. i know that it's most probably easy but i simply don't like it. It's totally irrational, i know, maybe i'm too old )
Anyway - there is one big advantage of GitHub - it has public API, so theoretically possibility to implement "publish" or "download" from/to github directly from Mozaic interface literally with one-button click :-)
Of course in case Bram will invest some of his precious dev time to such feature )
Having seen this conversation for a number of platforms....
Git hub is great in a collaborative environment where you want code reviews prior to submission and need a workflow around it - for plain sharing it's overkill, and sufficiently complex that you will need to constantly refer to the manual unless you are using it day in day out. It also requires a certain amount of discipline - ie don't post broken code etc. Even in professional environments were it is being used all the time you see a certain amount of "oh no what's happened" kind of issues arising
Patch storage does seem ideal especially if they are open to it. I've also seen people use GitHub to host their own source (I do this a bit with my bits and pieces of open source) and post the zips to patch storage - that way if small groups do want to collaborate you have the best of both worlds.
(edit: it's amusing that in most conversations about this I've seen - it's the regular GitHub users that are most against using it in this way ;-) )
Yeah.. I'm leaning this way too. Patch Storage seems like a neat place for easily sharing presets. The appeal of Github for me is collecting working, 'readable' code examples in one place - but beside the complexity of getting stuff on there it also requires some discipline with adding comments to make things findable (also via seach engines).
So Patch storage may be a lower threshold solution in this case - which fits the spirit of Mozaic.
FWIW I use patch storage for my Organelle (another tool with a great user community) and patch storage works really well. Norns from monome on the other hand have gone down a different GitHub/forum route and well, let's just say - I reckon that may well change sooner or later......
I think readable examples - IF you are prepared to put some work in on it - then a wiki/cookbook is likely the best approach here. But since you get the code with the patch - it's often easier to read/learn on the app itself. One of my friends regularly points out part of the success of the web was 'view source' making it really easy to learn how a web page was doing something
I use github/git a lot, but I think it's probably too high a barrier for non-coders
I agree that Github isn't the right place. It isn't a matter of being a coder or not--it is a matter of github familiarity. While many love it, most forget the learning curve that went with getting up to speed with it.
Enjoying Mozaic very much, I'm a games programmer by profession and have gotten used to using some lazy coder assist software which can help with syntax.
As such I've got a couple of non-essential feature requests:
When you start writing a function and select from the auto suggest list on the right, could you also add the @End a couple of lines down, I find myself repeatedly doing this.
Could the auto-complete list included user variables? I often find I have to scroll back up to the @OnLoad function to remember exact spelling of my own variables.
It's already great as is, but just thought I'd ask
At this point, I don’t think I’m within the intended user demographic for Mozaic. I'm merely curiously on the fence. Thing is, I think I’d rather just buy a midi app that’s been well thought out, tested, and designed by a creative and talented developer... versus attempting to make my own or edit someone else’s. Besides that, my usage and functionality desires aren’t anywhere as specific as many of the users here who obviously enjoy tinkering.
That said, I’d say all the comments regarding all the hoops and platform specific learning curve of github... just to freakin share and swap scripts, ended up pushing me further up the fence.
If @brambos Hope is to coax non-coders to wade into the deep-end a little, I think I’d go with the most user friendly sharing platform available. The patchstorage option sounds like a more straight forward option than the github one, but I don’t know much about either.
I think I had a brief encounter with github during my exploration of VCV Rack plug-ins/scripts and I do recall it being a somewhat confusing platform to figure out.
Yes. The same would be nice for IF and FOR loops.
YES to this to
I live in github for work and personal projects. I think it’s awesome for this, but you shouldn’t use it It’s just too much effort for maintainers of the repo. People will be creating branches to add their stuff, doing pull requests to merge those to master, and some poor sap will have to deal with all that. I don’t want that to be @brambos.
Yeah.. I’m definitely leaning towards Patchstorage