Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Any tips resolving build error for Cem Olcay project?
@cem_olcay I'm finally getting going trying to learn a little MacOS/iOS development, so far just with Swift/XCode. I'm able to build a few of the github projects without error: several of the large AudioKit examples, Cem Olcay's Music Theory library. I have freshly installed XCode and MacOS newly updated to Monterey. I have an M1 mac and had to resolve some issues like (I think) needing to run 'pod' under Rosetta to get it working right. Haven't neede to resort to any of that since updated to Monterey.
I really want to get Cem Olcay's MIDISequencerAUv3 project working ( https://github.com/cemolcay/MIDISequencerAUv3 ). It gets almost through building before it comes up with this error:
not all .o files built with same Swift language version.
Started with (5 or later), now found (4.1/4.2) in
file '/Users/herbertsitz/Documents/new/MIDISequencerAUv3/Pods/
AudioKit/iOS/AudioKit.framework/AudioKit' for architecture x86_64
I can't figure out where the issue is, any config specs I can find re: Swift are for version 4.2, so I don't understand why anything's compiling with Swift 5. It seems this error may be a rare one, because I google and find next to nothing.
Anyway, I'd be happy to find some way to work around this if anyone has a quick fix. I assume there's some way to use a local version of AudioKit, which I've been able to build separately from its associated github project. I assume I have more control that way. But I'm new to XCode, and all its configuration settings and use of pods, so not quite clear how to do it. Thanks for any tips . . .
Comments
@hes This may not help, but the error applies to architecture x86_64, i.e. Intel. If you don't need an Intel version, can you tell XCode not to build it?
Have you tried renaming that folder so it doesn't find it?
I have no clue of iOS development but I have a long history as developer with other technologies. My bet is that one of the dependencies that the project pulls in is causing that, most probably AudioKit. Excluding a build for the Intel architecture is also a good idea. Probably in this file: https://github.com/cemolcay/MIDISequencerAUv3/blob/master/Podfile
I agree with @krassmann the issue is most likely in one of the pods. I don't have CocoaPods installed/setup on my dev machine so I can't trace which one of them might be causing the issue. (I really dislike both CocoaPods and Carthage and wish that everyone would stop using them and move to Swift Packages or GitHub dependencies instead.) The pod file and the Xcode project file both say Swift 4.2 but maybe a change has been made to one of the pods. I noticed that in some of his own dependencies (like LiveKnob and MusicTheorySwift) Cem has updated to Swift 5. Maybe there is a problem with the way CocoaPods is pulling the version dependencies with those.
The other place I'd suspect is if you have added any of your own Swift files to the project. In the version I just pulled down from GitHub, the SWIFT_VERSION setting in the main build settings wasn't set for BasicSequencerAUv3. It should resolve to 4.2, but you may want to try setting that to 4.2 by hand.
What target were you building for? Note that if you are building for a simulator target on an Intel based Mac that you will be building for x86_64,
Thanks. I'm not sure if that x86_64 is actually part of the puzzle or not. Even though it's on an M1, it's being compiled to run in the iOS simulator; I have no idea what sort of code the simulator uses. And Rosetta could be figuring in somewhere transparently.
It takes about 60 seconds to open a github project and try to compile it. I wonder if someone might try opening that project and seeing if it compiles without problems on their machine.
Yeah, I'm just getting started in Mac/iOS world. It does seem to be an Audiokit issue, but Audiokit builds fine as a separate project; it's the Audiokit pod that seems to create problems. But also, I don't know why what the message says would be true (that the other parts of project are using Swift 5) when all the other parts of the project have Swift 4.2 specified in their build settings. In short, it's complex enough and I'm new enough at this that I'm skeptical I'll find the fix. But I bet it's a simple fix for someone who's familiar with the programming ecosystem.
Thanks, I think I need to do some learning about the dependency management. Yes, I'm building for simulator target. Trying to build exactly as project comes from github, nothing added. Not sure about build settings, after I got the error I went through and specified 4.2 manually wherever I could. I will rinse and repeat, or just give up on this for a while and (maybe) come back to it later. It's much more fun to work on a program itself than to struggle with getting it just to build. Especially when my understanding of the build system is pretty meager.
When you say 'Swift Packages' are you talking about some system that automatically pulls off internet? Or is that the old-fashioned way of downloading source for a project and compiling it into a package locally that you then reference from other projects?
Swift Packages is the new fangled way of doing both of those things. It's really just Apple's (and Xcode's) builtin system for doing package management. It can be used locally or via GitHub (for example). Its main use is as a replacement for CocoaPods and Carthage. Its biggest advantages is that it doesn't require external dependencies. Carthage projects for example usually start off with a step of telling you to install Homebrew which is just silly. If I remember the CocoaPods workflow correctly, you need to run the pod step before you start working in Xcode and that's a weird complication to have to deal with (they may have changed this now, but I don't really know either way for sure.) The big disadvantage of Swift Packages is that Apple was very late to the game with it and there are tons of projects that were started before it was released that won't ever be updated to use it. The same thing is basically true with GitHub dependencies.
It really is a pain to work on a project where the first thing you have to do is sort out the package management system failures. Maybe it would be easier to start one where you used some of the dependencies directly so you could get the feel for how they interact with Xcode. I noticed that Cem's MusicTheory library has both CocoaPods and Swift Packages supported.
@NeonSilicon Thanks, I guess it's all a good learning experience. Better to try to get relatively clear about things now than continue fumbling my way through, even if I could fumble through. And of course there's lots more than just the build system that will be strange to me.
All I want right now is a basic AUv3 project template with midi support. Don't care about audio at all. Cem Olcay's project seems much more distilled down to what I'm after than AudioKit's AUv3 sample app, which is an entire synth. So maybe it will be a good learning experience to strip Cem Olcay's little sequencer project down and try to build it back up.