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.
Comments
Good to hear the opinion of someone who's from head to toes in this stuff. Thanks @sonosaurus for your input.
^Yup.
That was quick Johnny. I can picture you in your sleeping bag with your index finger on the refresh button.
Not just clock, but synced Transport functions as well (start/stop/pause/continue/record), those are important too.
@sonosaurus - are you saying that the MidiBus SDK really does not supply tools for Midi reception? I suppose if you were the best Master, and you knew it, there would be no need for you to be the Slave.
For my money, a good iOS Midi monitoring app MUST be able to spy on ALL the messages passed back/forth from CoreMIDI, not just the messages appearing on virtual ports (because apparently not all apps use the virtual ports).
@ehauri said:
Midibus SDK supplies tools for connections and reception of all MIDI data, but it has no tools to help an app sync to incoming clock messages, which is not trivial to do robustly.
I want to get there in time...
There's one word that sums up why this is going to become the standard. Execution.
Make it happen... Je suis MIDI...
@HoldernessMedia said:
Motivate anyone to get it right.
Working,reliable,rock solid Midi Sync?On iOS?Please don't say i'm dreaming this thread.
Now, it's possible that Michael will put more functionality in his library with regards to midi connections, etc, making it overlap more with what the Midibus SDK provides. And it's possible that Midibus ends up adding some sync reception support. If either of these things happen, GREAT, because that just increases the chance that a developer will use either one of them and that increases the net quality of MIDI-ness across the platform. Compatibility is a non-issue because the MIDI standard defines it, and presumably both will do a good job providing it.
I'm glad to see Sonosaurus in favor of this.
More MIDI-ness!!!
@sonosaurus thanks for clarifying the issues. It seems like Michael's attempting to fill in a critical void for midi sync and it should probably be a case of a high tide floating all of our boats.
But remember this still requires the captain of each boat to first pull up his anchor
Build it and they will come! Especially if it is easy to implement...
And it is up to all of you to stand on the decks of every boat and yell at the captains!
There is a new communication system (wireless) Semaphore which might be useful for this (perhaps coincidental that it is also a variable or abstract data type that is used for controlling access by multiple processes, but I get ahead of myself...)
@JohnnyGoodyear said:
Sorry but I'm going to have to Flag this post.
?
Semaphore .....
@sonosaurus said:
Ai Ai Sir!!!
Haha!
I've signed up to support this, but have PGMidi, WIST & Midibus solutions in midiSequencer.
The midiBus library does not currently have midi time code (24 full/quarter frames usually over sysex), just midi beatclock (start/stop/continue/tick - but this is accurate).
What's the difference? MTC supplies the frame in the message, so is bulky and really only as accurate as the sending system. If that is IOS - as Michael says IOS/OSX are not realtime systems (I can't get anything better than 1ms sometimes and have spent weeks looking for solutions).
With beat clock, there is no positioning - its all relative - you just count the ticks from the start.
If people start using MTC then they may well introduce new issues in syncing as the receiver may not be able to process fast enough.
If this solution is just beat clock, well yes we already have this in midiBus - just no input - but the solution to this is easy (just process midi clock ticks fast, don't hold up the thread and display bpm). I do this in midiSequencer for SLAVE mode.
It's a tough job to do midi sync in IOS - that's why I've stayed away from it.
and WIST? Well that's flakey and only supports stop/start but does at least communicate host time (timestamp).
When we were pondering as to what we would like to see on iOS, this has to be the 'biggie', the dream is coming to life, timing is everything, I can only hope that time has come, thanks for your work.
Ios/osx not realtime... Maybe, but what is os faster?
@Goozoon said:
Think this may have been in relation to hardware OSes. My crap 90s Alesis drum machine's OS will sync to any of my other hardware like a champ. Usually only requires plugging a cable in. For the Alesis and a few other low rent boxes in my studio, incoming clock is detected automagically and simply followed if present. Like, "just works".
Your 'crap' alesis drum machine was written in a assembly and had a dedicated processor - unfortunately all the bloatware we get with modern OS's means it's running hundreds of concurrent processes - not many of them related to keeping our loop timing sample accurate.
In this respect dedicated hardware, however old, will always be more accurate.. I can't get IOS to be more than .1 ms accurate - and sometimes it just does something weird and jumps to 40ms.
60 bpm = 1 sec for each beat, so in 4/4 time this is 250ms per quarter note. If you want to run a clock tick at the highest 960ppqn that 250/960 = 0.26.. ms (this is nearly 4000 per second)
if you run at a miserly 24ppqn, then this is still 250/24 = 10.42ms (96 per second).
The above is for midi beat time of course : start + tick at regular intervals.
midi clock time (and indeed miditimestamps) gets around this by specifying the exact time (full or quarter) of each 'tick'. But not many ios apps employ this smpte format and it does have it's own problems with jitter.
I guess with midi clock we have a similar situation to bit rate, sampling frequency or compressed vs uncompressed. I've played live shows with loopy, samplr and turnado sync'd and I could just about get away with it because the imperfections of the live drumming covered up most of the sync problems. I know we can get very anal-itycal regarding the clock and count .1ms of dis-sync. For me as long as it grooves together I'm not too worried about it. Having said that, if there's a hihat playing 16ths it better stay in tight with that choppy arp or we're in trouble.
I wonder if allowing the user to set prioritizations on a per app basis would help. Just a pipe dream, I imagine, but it seems that could help.
Audionics just pasted this over at Discchord
"This video" being the one where Michael announces his sync engine.
"What is described in this video is pretty well what the MidiBus library does now. It’s been available for over a year and around 130 developers have requested access. There is a growing number of existing apps using the library (just over 40) and more are in the works. Details at audeonic midibus. It provides the most accurate outgoing clock (this is verified) as well as setting things up MIDI-wise to make an app ‘behave nicely’ (including OMAC MIDI controlled app switching) in the iOS MIDI world out of the box with minimal effort required by the developer. It is freely available (even to Michael Tyson) for both iOS and Mac OS X. It’s actively being worked on (MTC generation is next) and diligently supported. There is also documentation on how to set up a ‘model’ app to handle incoming sync that is not tied to any particular audio engine. A number of apps are using this model and it is working well for them.
The MidiBus utility app already measures error and latency on incoming clock signals and that has also been available for over a year.
Tackling the MIDI ‘discrepancies’ under iOS is something I have been active in for quite some time now based on my experience with MIDI interconnectivity apps. John Walden’s Music App Blog (see Music App Blog) has a very comprehensive article on this subject for anyone interested.
I would go as far to say that I feel it is extremely disingenuous of Michael to claim that ‘there is nothing around’ in the video. It’s been done and is already here."