Question about app development vs scripting for iOS/iPad OS

Samflash3

@yug said:
C is fine, I love C but... I wouldn't start with it.

When you start developing an app or a desktop program, you never know how your code will look at the end (unless it's something very, very simple). You try diff ideas - some work, some don't. You usually rewrite some parts of your code several times, you do some refactoring when it starts to look messy.
My point is: it's much easier to do when you use a higher-level language like Python or Swift. Then, when you are happy with your prototype and you need some of your code to be cross-platform and/or faster, you can rewrite it in C. Like writing a book - you don't start translating it into other languages when it's not finished yet

Yeah, this was what I experienced with the Beatmaker script I did on Shortcuts. Re-did a lot of it, but half of it was trying to find ways around the limits of iOS Shortcuts. That's why I was looking for something a bit more powerful.

So, it's iOS scripting (Pythonista, Shortcuts, Scriptable) for the prototype/test quick ideas, and JUCE (C/C++) for me until I can get a Mac to use Swift and the AudioKit tools. I'll probably make my iOS scripts code more script heavy (Pythonista), less iOS Shortcuts to make it easier to troubleshoot, but it really depends on the tool.

@Blue_Mangoo No need to apologize. You mentioned a lot of good tips. @bleep seems to agree as well. Interesting you prototype in MATLAB. That used to be my main application until 2015. I've been meaning to revisit it (or NumPy) for DSP signal processing, but I gotta overcome this programming roadblock.

Here was an advice from my professor regarding libraries. It's fine to see how they work. But open them, and see the section of code you are actually using, then take that piece and adapt it to your program.

coniferprod

You might want to take a look at Will Pirkle’s books about creating plug-in effects and synths:

https://www.willpirkle.com/about/books/

Lately I’ve been having a lot of fun working with the stuff from those books in the context of Windows 10 and UWP. There is a set of APIs in UWP called AudioGraph, which does not have a plug-in architecture like VST or AU, but does allow you to create custom effects and synths and hook them together just like Core Audio.

The books’ code is C++, but I’ve been working in C# since it’s not that different on the raw processing, but it’s easier to set up the UWP UI in C#. You can write UWP apps in C++ too, or create a static C++ library to use from the UWP app.

I’m not saying that you should use this, but am just pointing out that the AudioGraph in UWP is a way of getting into audio development with very little overhead, at least when compared with Audio Units. So I’m using it to stockpile skills to make the leap over to AUv3, even though I’m an iOS developer since the Objective-C days, and work mainly in Swift.

You will need the C++ anyway, because JUCE is C++, the audio rendering code in AU is C++, and even the KORG logue SDK user oscillators are in C++ for ARM. (I thought I was done with C++ already in 1997, but apparently not.)

wim

OK @Samflash3 here's my brain dump. I'm basically in the same spot you are, maybe just a tiny bit further down the road.

After looking into it I concluded that a Mac is necessary if I want to be serious about developing apps for iOS. I've been primarily Windows focused forever, with healthy doses of Linux, and a tiny bit of Mac. The only PC I owned up until a few days ago was an aging Windows 7 notebook. I thought about the Hackintosh or Hacintosh in a Virtual Machine route, but I just didn't want the hassle. I decided to go for a used 2015 MacBook Pro that I could pay for in 12 interest-free payments to lessen the immediate financial impact. Now that I have a few days with it, I'm convinced I made the right decision for my case. I'm super-happy.

But ... it was some time before I got to this point, and like you, I didn't want to waste the time while I did. Here are some of the things I did and learned:

I looked into Juce, having learned that Gadget, Beathawk, and other apps are based on it, that it's free, multi-platform, and that it can be used on Windows. I never took it far largely because my PC was out of space and because I knew I would need a Mac anyway. I may still go back there. It's certainly something you could look at if you're stuck on Windows for awhile and plan to make music apps.

I then took a foray into learning Python. At first this was because I got Pyto when it was briefly free, and could play around with it on iOS. This led to the many, many great tutorials out there for Python in general. Finding it too frustrating developing on iOS, I installed Python on my Windows PC, and then would take those scripts over to my iPad and iPhone just for kicks, to see what would work or not (most things do). I mention Python because now that I'm learning Swift, I find that my Python learning has made that process easier. That has been time well spent.

I got bored one day and decided to take another side-trip into Linux Land. I decided to check out MX Linux, a currently popular distribution that I hadn't seen so far. I was so pleased with it that I set it up on an SSD I had laying around, and was having fun booting it instead of Windows. At the same time I was looking more into AudioKit. This led to realizing Swift was probably an easier route to learning iOS development than most. That led to realizing Swift runs on Linux. So, there was my way to begin learning Swift while I ruminated over whether to buy a Mac now or not. (It's only officially packaged for Ubuntu, but I was able to get it working on MX by overcoming just a few hitches. Ubuntu recommended though I'm not a fan.)

While Swift runs on Linux, it becomes apparent quickly that it only really shines on MacOS. This led to learning about Xcode. That sealed the deal on me buying a Mac eventually. Xcode is a thing of beauty IMO for someone like me that doesn't have a lot of grounding in lower level non-IDE based development. However, I kept up with learning Swift on Linux, and I'm really glad I did. The problem starting off with fancy IDEs like Xcode is they can shield one from the need to understand the underlying source code structuring, packaging, and build mechanisms. You have to learn that stuff on Linux. So now I feel like I have a better foundation on which to build on getting into Xcode.

So here are some ideas for going a long way with little to no investment:

1. Dive into Juce. You can make fully functional VST's that run in Windows DAWs. You can get Ableton Live Lite for free with several iOS apps. Those VST's can be made eventually into iOS AU's as demonstrated by Beathawk.
2. If you have any kind of USB hard disk available, set up Linux on it and dive into Swift. Ubuntu might be the best since Swift is packaged specifically for it. Just be really careful when you install Linux not to install the Grub boot manager onto the Windows HD of the PC unless you want to have it always trying to boot Linux from the hard disk. Most distributions do this, so you have to be careful to make sure they install Grub on the external HD. On a side note - I found the best code editor for Swift on Linux to be the free Windows program Notepad++ running under Wine. I didn't find much with syntax highlighting, short plugins in heavy IDEs for Swift in Linux.
3. Another low-impact way to mess with Linux is to set it up within Virtual Box under Windows (or MacOS). Totally free, and you can't screw up your system that way. Another great thing about it is you can take a virtual machine snapshot before trying something new like installing an app, and revert to that snapshot in an instance if things to tits-up.
4. Read up on Xcode. While little of it really stuck since I wasn't doing-while-learning, still, following and understanding getting started tutorials was time well spent.
5. Read up on AudioKit. The beauty of that is there are so many examples, and the source code itself is open. I've learned a ton by drilling down to see how something that is handled with a line or two of AudioKit code is actually implemented in the underlying libraries. This is time well-spent as I plan not to use any AudioKit libraries I haven't at least dived into to get a basic understanding of how they're implemented, and because they all seem to be well-structured and quality controlled. I think they will serve as good examples for the discipline I hope to exercise in my own coding.
6. There are plenty of concepts in Python that aren't difficult to transfer over to understanding Swift and probably other languages. Python is so accessible and interesting that it has very low barrier to entry.
7. All of the Audiobus developer documentation is invaluable. I haven't dived into it and into other iOS developers such as j_liljedahl's writing as much as I plan to yet.

The MacBook is here now, and it's beautiful. So far I feel like the refurbished MacBook Pro 2015 is a perfect balance between cost and power for my personal situation. Xcode is a beautiful thing. I'm going to have to be disciplined about not shortcutting the learning process though because of how much burden it lifts over details, and to be patient about this journey so that I do it right.

-cheers!

[Deleted User]

The user and all related content has been deleted.

wim

Thanks @tja. I'm glad you found it useful. I'm pretty stoked about this new direction for myself, so I wanted to share for anyone else that is thinking of heading in similar directions.

Samflash3

@wim said:
Thanks @tja. I'm glad you found it useful. I'm pretty stoked about this new direction for myself, so I wanted to share for anyone else that is thinking of heading in similar directions.

Whoa, thank you for this. I love the knowledge that you instilled, and the time to explain your path. Thank you.

wim

@Samflash3 said:

@wim said:
Thanks @tja. I'm glad you found it useful. I'm pretty stoked about this new direction for myself, so I wanted to share for anyone else that is thinking of heading in similar directions.

Whoa, thank you for this. I love the knowledge that you instilled, and the time to explain your path. Thank you.

You're totally welcome.
(Edited because I forgot to mention Linux running under VirtualBox. A great low-impact way to mess with Linux.)

McD

It worth mentioning there's an $8 app that runs a complete IOS Music scripting engine that's in an AUv3 package. It's not trivial to learn but you'll be making simple apps in a few days as you learn the concepts of "event oriented" programming from standard User input to a DAW.

There's no money in it but it helps prototype musical apps as a proof on concept. Lot's of expert support too.

Just a thought... see if programming for ideas is fun or torture. The torture will be using the supplied editor.

[Deleted User]

The user and all related content has been deleted.

[Deleted User]

@wim JUCE is not free. If your revenue per year reaches 50K or if you don’t like their “Made with JUCE” splash screen, you have to pay
https://shop.juce.com/get-juce

hes

@McD said:
It worth mentioning there's an $8 app that runs a complete IOS Music scripting engine that's in an AUv3 package. I

I assume this is Mozaic. I agree, great app, but people should realize it's strictly a midi tool, no audio processing is going to be done in Mozaic. This is a plus for some, minus for others, I'm sure.

While a great combo of UI integration with midi scripting, Mozaic language is somewhat infuriating to anyone coming from a more full-blown, general purpose scripting language. I haven't used it, but I'm curious about the combination of Pythonista with the ios app, MidiFire. Programming midi in Python(ista) would be a treat. I'm curious if there are any other code examples out there:
https://audeonic.boards.net/thread/734/adding-scripting-languages-using-midifire

Samflash3

@hes said:

@McD said:
It worth mentioning there's an $8 app that runs a complete IOS Music scripting engine that's in an AUv3 package. I

I assume this is Mozaic. I agree, great app, but people should realize it's strictly a midi tool, no audio processing is going to be done in Mozaic. This is a plus for some, minus for others, I'm sure.

While a great combo of UI integration with midi scripting, Mozaic language is somewhat infuriating to anyone coming from a more full-blown, general purpose scripting language. I haven't used it, but I'm curious about the combination of Pythonista with the ios app, MidiFire. Programming midi in Python(ista) would be a treat. I'm curious if there are any other code examples out there:
https://audeonic.boards.net/thread/734/adding-scripting-languages-using-midifire

The Groovebox ALS to MIDI code that @MrBlaschke worked on was made with Pythonista. It's that project that inspired me to dive deeper into scripting.

wim

@yug said:
@wim JUCE is not free. If your revenue per year reaches 50K or if you don’t like their “Made with JUCE” splash screen, you have to pay
https://shop.juce.com/get-juce

It's free in the context that I was speaking of ... getting started.

wim

@hes said:

@McD said:
It worth mentioning there's an $8 app that runs a complete IOS Music scripting engine that's in an AUv3 package. I

I assume this is Mozaic. I agree, great app, but people should realize it's strictly a midi tool, no audio processing is going to be done in Mozaic. This is a plus for some, minus for others, I'm sure.

While a great combo of UI integration with midi scripting, Mozaic language is somewhat infuriating to anyone coming from a more full-blown, general purpose scripting language. I haven't used it, but I'm curious about the combination of Pythonista with the ios app, MidiFire. Programming midi in Python(ista) would be a treat. I'm curious if there are any other code examples out there:
https://audeonic.boards.net/thread/734/adding-scripting-languages-using-midifire

There are many midi libraries for Python. I haven't tried any of them though. I'm not sure if there is any compatibility layer for Core MIDI.

hes

@Samflash3 said:

The Groovebox ALS to MIDI code that @MrBlaschke worked on was made with Pythonista. It's that project that inspired me to dive deeper into scripting.

Is that something that works with midi in realtime, or just a utility that converts a file's format? In any case, do you have a link to that project?

Samflash3

@hes said:

@Samflash3 said:

The Groovebox ALS to MIDI code that @MrBlaschke worked on was made with Pythonista. It's that project that inspired me to dive deeper into scripting.

Is that something that works with midi in realtime, or just a utility that converts a file's format? In any case, do you have a link to that project?

Here's the project on our Wiki...
https://wiki.audiob.us/pythonista_als_to_midifile_converter

This was the thread that inspired it
https://forum.audiob.us/discussion/36093/any-apps-that-can-read-ableton-als-files/

[Deleted User]

@wim said:

@hes said:

@McD said:
It worth mentioning there's an $8 app that runs a complete IOS Music scripting engine that's in an AUv3 package. I

I assume this is Mozaic. I agree, great app, but people should realize it's strictly a midi tool, no audio processing is going to be done in Mozaic. This is a plus for some, minus for others, I'm sure.

While a great combo of UI integration with midi scripting, Mozaic language is somewhat infuriating to anyone coming from a more full-blown, general purpose scripting language. I haven't used it, but I'm curious about the combination of Pythonista with the ios app, MidiFire. Programming midi in Python(ista) would be a treat. I'm curious if there are any other code examples out there:
https://audeonic.boards.net/thread/734/adding-scripting-languages-using-midifire

There are many midi libraries for Python. I haven't tried any of them though. I'm not sure if there is any compatibility layer for Core MIDI.

No, CoreMIDI is not supported.

I haven't tried it too, but I think the combination of Pythonista and Midifire described above should work fine
I had some success using Pythonista/OSC library and a simple PureData-based OSC-to-MIDI bridge I created for Mobmuplat. It was years ago, so I don't remember if there were any limitations, etc.
Now, I would use MidiFire as it looks like a better solution

[Deleted User]

The user and all related content has been deleted.