A big question and suggestions
Hi Christian,
so far I'm liking Everest a lot. Over the years, I've used a lot of both hardware (Ditto, Vox Dynamic Looper) and software (Augustus Loop, Möbius, LoopyHD) loopers and I've even made a couple of attempts at programming one myself in SuperCollider.
Now that I've figured out how to connect my RME Babyface to my iPad my interest in using it as a performance tool has been revived and I can very well imagine Everest being a part of my performance setup.
What I like most about it are the detailed geeky options, the Replace and the multiply function and the multiple undos. With those options I can't really imagine how I would ever need more than two loops at once.
I have one big question some critique and suggestions.
The big questions is: How do I route the sound that goes into the looper through to the output? At the moment, I only hear sound once Everest starts to loop. So far, I've only tested it standalone but I do plan on trying it in Audiobus as well so I can put a couple of effects apps in front of it. So I need to hear my preprocessed sound as I play. Am I missing something?
My critique concerns the mechanism that tries to guess the numbers of beats my loop is going to last. It doesn't work well with odd beat numbers as it tends to force me into a certain tempo. I thought about this problem a lot when I designed my own looper. The problem is it's just impossible to guess a number of beats just from a duration. If the player uses some sort of a standard tempo, it might work more often than not but I don't like this restriction. I would much prefer a simple way of telling the looper how many beats I'm going to play before I record the first loop. It could default to 4 or 8 beats which, even if I chose not to adhere to that, would give me a more predictable behavior. I'd love to hear your thoughts about that.
I would also like to have a better visual representation of where in the loop (on which beat) I am at the moment. Something like a colored bar that's divided into the number of beats of my original first loop. The current solution just confuses me.
One last (almost negligable) suggestion: the pan sliders on the mono input panning page should have a center position... < /nitpick>
I'll write more later. For now, I'm mainly interested in solving the audio through issue.
Cheers,
Axel
so far I'm liking Everest a lot. Over the years, I've used a lot of both hardware (Ditto, Vox Dynamic Looper) and software (Augustus Loop, Möbius, LoopyHD) loopers and I've even made a couple of attempts at programming one myself in SuperCollider.
Now that I've figured out how to connect my RME Babyface to my iPad my interest in using it as a performance tool has been revived and I can very well imagine Everest being a part of my performance setup.
What I like most about it are the detailed geeky options, the Replace and the multiply function and the multiple undos. With those options I can't really imagine how I would ever need more than two loops at once.
I have one big question some critique and suggestions.
The big questions is: How do I route the sound that goes into the looper through to the output? At the moment, I only hear sound once Everest starts to loop. So far, I've only tested it standalone but I do plan on trying it in Audiobus as well so I can put a couple of effects apps in front of it. So I need to hear my preprocessed sound as I play. Am I missing something?
My critique concerns the mechanism that tries to guess the numbers of beats my loop is going to last. It doesn't work well with odd beat numbers as it tends to force me into a certain tempo. I thought about this problem a lot when I designed my own looper. The problem is it's just impossible to guess a number of beats just from a duration. If the player uses some sort of a standard tempo, it might work more often than not but I don't like this restriction. I would much prefer a simple way of telling the looper how many beats I'm going to play before I record the first loop. It could default to 4 or 8 beats which, even if I chose not to adhere to that, would give me a more predictable behavior. I'd love to hear your thoughts about that.
I would also like to have a better visual representation of where in the loop (on which beat) I am at the moment. Something like a colored bar that's divided into the number of beats of my original first loop. The current solution just confuses me.
One last (almost negligable) suggestion: the pan sliders on the mono input panning page should have a center position... < /nitpick>
I'll write more later. For now, I'm mainly interested in solving the audio through issue.
Cheers,
Axel
Comments
I have my guitar connected to one analog input of the Babyface and my mic to the other. I want to play only the guitar through Jamup, not the mic. Then I'd like to mix the two so I don't have the mic and guitar panned hard left/right on the output. I use StereoDesigner for that on the effect slot in Audiobus. Finally, I want to use Everest at the end of that chain....
I just tried it for the first time and it worked!! :-) It's totally unintuitive and I have no idea why it works though. Does Audiobus route the input audio parallel to the app on the output bus? Or is it some internal switch that puts Everest in monitoring mode as soon as it's in Audiobus?
It's funny, at the beginning ios was so primitive. It was too primitive to do much more than wipe your finger across that sceen to make some funny noise. Then people began to build workarounds for its limitations. Now ios is still far less capable than OS X but it's much more complicated and intransparent in many ways.
I have more than 15 years of experience making music on a Mac and more than 5 years trying to realize what's in my head on ios. I do understand mixing consoles and I even know a thing or two about audio programming... and I'm totally confused about how audio routing in ios works.
Sorry for the rant ;-)
First off, thanks for all this feedback and insight. This is great stuff!
Second, let me address your experience with monitoring:
Yes, Audiobus is routing the audio to your hardware output in parallel to Everest. in my implementation of Everest as an AB Receiver, I opted in to automatic monitoring. This is something developers can turn off; it is on by default. I think if an app does its own monitoring, its developer would want to turn this off explicitly in the code.
For me, this was a great way to get multi-app monitoring for those that needed it, without having to implement it all myself (apart from implementing AB). I figured: many iOS users who would want software monitoring would be using Audiobus anyway. This is especially useful considering that one of the inputs to Everest under AB is the Microphone/Hardware input.
Tech Details: Audiobus, from what I have seen in the debugger, uses a combination of Inter-App Audio and some form of IPC (kernel shared memory, sockets, etc.) to pass audio in and out of the various apps in its "network" of connected apps. So, the audio output from each app, and the hardware, is being stored in the shared memory space (i.e. kernel) of this audio network. It is then very easy for the Audiobus app to write out (i.e. monitor), or NOT write out the audio data coming from each source/sender to the hardware output bus on each render cycle. Does that help clarify? Core Audio is a deep API with lots of dark, thinly-commented corners. It took me years of trial and error to figure some of this stuff out. :)
You are totally 100% right. It's actually a relief to hear someone else make the same observation as me! It is seemingly impossible to determine, in any musical way, what the tempo should be from an arbitrary sample length/recording. That said, I decided to make the best compromise I could:
1. If you are hosted by another Inter-App Audio host app, like Garage Band or Cubasis, then your tempo and beat length is decided there. Everest will lock to the host tempo and any loop you make will be quantized to a quarter note.
2. If your first loop is short it will BE the length of the 1/4 note in the resultant BPM. How short? I set a lower limit of 60 and no upper limit. So, if you're first loop is shorter than one second, that first loop is your BPM, and all other loops will be integer multiples of that length.
3. If that first loop is longer than 1 second, Everest will begin repeatedly dividing it by powers of 2, until the resultant beat falls and stays above 60 BPM. This covers many musical subdivisions, though it does prevent short asymmetric time signature phrases from establishing the BPM. In practice this works well: Even if your time signature is odd, like 5/4, because many musical phrases, of even that measure length, are a power of 2.
The lower limit of 60 BPM came from Inter-App Audio. In my testing, it seemed that many apps could not handle a lower tempo. I think this is because the lowest for Garage Band IS 60 BPM.
I added two facilities to make following tempo easier, considering the above algorithm:
1. You can add a generator app to create a metronome (FunkBox is wonderful in this scenario). You can even then route it to its own output bus so the audience won't hear it. However, I don't know how this works when hosted by Audiobus, as they kind of take over the audio hardware routing.
2. You can create a short loop, like two sequential taps on a tap tempo hardware device/pedal, on a loop track you won't be immediately using. Possibly pan that track to some unused output bus. This will allow you to set a very precise BPM and have new loops be of arbitrary musical length. Lot's of fun time sig. phasing possibilities here. ;D
I definitely think having an option to give a "suggestion" to Everest about the first loop's true length could work. First, let me know if the above works/seems reasonable. I really wanted the sync to be as immediate/fluid and option/hands free as possible.
I think I know where you are headed... An averaging function based on more than just two taps? I think I could add an optional switch for that. One thing that isn't clear is what would happen if Everest needed 3+ taps, but only got 2 taps...
Another option would be to manually set the tempo under the settings menu before any loops are recorded. With some dedicated tap button. Probably even a dedicated MIDI switch, where a hold would "free"/erase the current loop-less set beat.
Maybe I could even repurpose Undo/Redo/Bounce/Multiply(?) for that purpose, since they don't do anything when there are no loops. Ideas are starting to flow.....
Fourth, on the current loop position ambiguity:
I also want to say that I agree: the lack of current beat position, within a playing loop, is a problem. I have plans to re-do large portions of the UI. One of them is to improve the beat display. This would include total length, window length, window start, and current position. The deeper levels of the code already have this information, but there is no UI for it. Finding a place to put it is part of the problem, but I am already refactoring/re-designing the UI to make room, perhaps optionally, for more numeric beat displays/information. Same goes for ticks/vertical bars under the waveform showing different musical positions.
Note: One feature of Everest that makes this a little more confusing than other loopers is that while it quantizes sample-accurately to the underlying beat of your first loop, it does not force you to start new loops or edits from any particular musical point. Let me illustrate with a specific example:
If you make a 4/4 four bar loop, then make another loop of the exact same length, Everest will let you start recording that new loop wherever you want. It will not force you to wait for the first loop to cycle to the beginning. If start quantization is enabled, you would need to press the Record button one quarter note/beat before you want to record.
One of the great things about this: if you start recording your next phrase midway through the original phrase, let it loop around (musically) with respect to the first loop, then finish recording before the next midpoint, you get half a phrase to prepare your next loop or pedal/effect change. If Everest forced you to make all changes based on the initial loop's phrase length (and not the beat) it would take longer to make changes to your performance because everything would lag behind by exactly that initial phrase length.
The exception to all this being when Everest is hosted in IAA AND you are traversing the undo history, but this is a more obscure point.
Fifth - Pan notch
yeah, I can't stand it either. I need to create a custom slider to make it snap to center. As far as I know the default UI slider does not allow for notching. It's really just a matter of time before this happens. However, if the panning UI is moved to the front screen, with a new custom UI, then it may not be necessary to change the settings version.
Thanks a lot for the clarification on the beat length calculation stuff. Now that I know how it works I'll have more clues as to how to work with it.
But I love crifytosp's suggestion! Having an option to use the duration between the first step on the record button and the second one, when the actual recording starts, as the beat length might be The most unintrusive (and cpu efficient) way of setting a tempo for a performer who doesn't want to play along with sequencers.
Of course that would confuse the hell out of the casual user who is used to tap tempo buttons, so it might best be buried somewhere deep in the settings screen.
Btw., I'm not a friend of averaging for tap tempo stuff. I think if someone uses a Live Looper to create precisely timed loops they should be able to set a tempo without an averaging (i.e. imprecise) function. I could live with three taps where the first and the second one are used for setting beat length and the third one starts the recording, so it would be like a 2 beat count in. But please don't make it imprecise by averaging.
"what would happen if Everest needed 3+ taps, but only got 2 taps"
Set a timer and if the function doesn't receive a second (third) trigger until the timeout it goes back to its default state... or something like that?
One last question (for now ;-) ): What does the quantize window length option do? I expected it to make freely adjusted loop windows snap to a beat position/length but this doesn't happen.
E.g. if the duration between the first and second tap was 1 second and the actual loop recording had a duration of 3.49 seconds (really bad timing), Everest would set the number of beats to 3. I believe this could work really really well for all possible time signatures.
Of course, I can't tell how hard it would be to add this mode to the existing one. In the meantime, I will continue to try to get to terms with the implementation as it is now.