Last Everest Update

I’ve been playing with Everest again for the first time in about half a year. The first thing I want to say is: thanks a lot. The last update has improved it immensely. I’ve been using and abusing it for about 3 hours now and haven’t had a single crash.

The improvement of the windowing functions and undo system are especially nice. At the moment I have all sync options switched off and I’m just using one single loop constantly creating new rhythmic patterns and it’s great fun.

I think I’ve also found a bug: When I pause the loop and hit restart it doesn’t restart the loop but unpauses it. Also, wouldn’t it make more sense to make the transport actually pause when you hit pause instead of the loop playing silently in the background? At the moment, pause is more like mute. This could have to do with that stupid IAA transport getting in the way of truly free playing?

All in all it has been a very good experience so far. That’s it for now. I’ll record some stuff and finally put a review on the app store in the coming days.


  • You are welcome! I am happy to hear that people are still using it.

    In terms of the possible bug: The logic between Pause, Restart and the global loop/tempo track definitely could be cleaner.

    Background: When the first loop is recorded, a global tempo and beat count is created. Each loop records its epoch in that global beat count. During certain operations, like Undo, the loop automatically jumps to a position that would match the original epoch of that loop. In other words, the loop playback position will be restored as if it was playing all along.

    However, this behavior doesn't always happen, as you have seen in Restart (from a playing loop). Oddly, a Restart from a paused loop just un-pauses the loop, without resetting the playback position. It definitely, IMO, should begin playback from the beginning. So I plan on fixing that small detail.

    Side Note; The Button Quantization switch will determine if this restart is quantized or not.

    In terms of Pause, it isn't clear to me which of these behaviors is best:

    1) Resume immediately (without Button Quantization)
    2) Resume on next beat (with Button Quantization)
    3) Resume to epoch-relative position. (current behavior, where Button Quantization just delays the audio starting till the next beat)

    The argument for #3, and my original reasoning, is that it _seems_ more useful to have the loops musically re-align themselves automatically, without having to follow an un-pause with one or two restarts in order to get the music to be back in phase with each other (which is the common case as far as I can tell.)

    All that said, it is possible to add this alternate behavior as an option to the settings menu, but I am wary of that because the options already seem overwhelming.

    I am open to suggestions, so feel free to comment on anything here.
  • Thanks, Christian, for your explanations. In my opinion, there should definitely be a possibility for option 1. As I wrote, the way I'm currently using Everest is to only use one loop and change its length freely through windowing, multiply and insert as it's playing. It's a little chaotic but I'm getting some beautiful results that I could never get with Loopy or any of the other ios loopers.

    The inital global beat length and count doesn't play any role in this scenario and scheduling a function to a point in time that's logical in relation to that initial beat length and count doesn't yield results that make musical sense. This applies to the pause function as well as to the undo / redo functions that atm also seem to be bound to "epoch-relative" quantization.

    I would be extremely glad if there was an option to use Everest completely independent from any quantization mechanism. Or at least as independent as possiblle within the given architecture.

    I also want to have the option of creating out of phase loops :-)
  • I've just noticed another thing.

    My current setup is: I have Everest loaded in AUM, the new mixer / IAA host app by Kymatica.

    When I create loops in Everest without engaging the AUM IAA transport (which I have to do in order to record what I'm doing) the functionality I want is already there, apart from the pause / restart thing we have already discussed. Undo / redo is immediate and restarts the loop. Perfect.

    However, when I start the transport in AUM in order to record, Everest is now slaved to AUM's clock and undo / redo is scheduled in terms of that clock (which is totally irrelevant to me.

    What would make most sense to me would be that if I have all quantize options set to off no scheduling to any clock should happen anywhere because my first loop wouldn't be aligned to any external clock anyway.

    Here are a few general thoughts and ideas:

    I still believe that Everest is right on the edge of becoming a fantastic and a truly unique tool, at least in the ios world. What for me sets it apart from others is its great undo system in combination with the windowing, the multiply and insert and the possibility to go from playing a loop to recording a new one in its place immediately. Those are extremely powerful features.

    Imho, a lot of the complexity that might be putting people off is that it tries to do too many things at once. If I were to decide on how to develop it further I would get rid of the bluetooth midi. I haven't gotten that to work with my Guitar Wing, but I use Midi Flow for that anyway. There's even a free app that does the Bluetooth connection stuff. I would also get rid of the IAA hosting. It's easy to integrate Everest with all sorts of other apps by using Audiobus (or AUM or any other IAA host). Instead of doing all the complicated routing stuff in the app I would make it a IAA / Audiobus effect. This way, people could do all the routing they want outside of Everest (and yes, there would need to be a monitoring on/off option).

    This would make Everest an incredibly lean and flexible app.

    I hope I'm not getting on your nerves with all of this. I just care a lot for Everest :-)
  • Hey Axel,

    All your feedback is very helpful; I appreciate the attention to detail... :)

    1) I agree 100% that there should be a way to have completely asynchronous loops, even when hosted by another IAA app. I will have to spend some time thinking about how to refactor the code so that this is possible.

    2) IAA has been a tricky thing for me as a developer... On the one hand it gives me something I can't find in many other systems: sample accurate sync. That is indeed the main reason I bothered to implement it at all. Obviously for your particular flavor of workflow, this is getting in the way. As described #1) above, if one disables quantization for a loop (or all loops), it really should intuitively NOT sync with a host, if not also ignore the transport altogether. I will investigate this confusing behavior.

    3) Apple have hinted at "sunsetting" IAA in favor of a pure plug-in model via AudioUnits. This is something I am actively investigating and may indeed be a better solution than IAA. Essentially, Everest would be launch-able entirely _within_ another application as a plug-in. I have a desktop prototype that works very well, but have yet to get it working on iOS (GarageBand and Cubasis have only added support for AudioUnits recently, so I didn't have a host to test). Of course, there are lots of open questions to consider as well... would the UI be severely limited? Is there a way to host a number of different Everest instances or just one? Is it possible for the AudioUnit to receive MIDI and Audio I/O from all hosts? What should the parameters be? Etc.

    4) I will look into having Everest in the Effect (middle) slot of Audiobus. I vaguely remember some reason not to do it...but I don't remember that reason now.

    5) I definitely agree that Everest may be doing a bit too much. The challenge with this app has been trying make everyone happy... which is probably a bit of a fool's errand; I do think I went a bit overboard on the feature set. The app might have done better had I split it up into multiple apps. I think I was just a little trigger happy when thinking of all the features I could add (people want even more at this point, not less).

    Going forward I have to strike a balance of shifting/simplifying features instead of cutting them out. It seems a lot like whack-a-mole: If I make one area simpler for some users by removing or disabling behavior, then I upset a different set of users in the process.

    I hope that clarifies your suggestions and my thought process going forward. If I think of anything else I will post it here.
  • edited March 2016
    Hi Christian, I'm still new to Everest but I already know it's going to be my main livelooping app. You've done a wonderful job and the latest update resolved most of the issues I had with Everest. Thank you!
    Btw., this is coming from what you might call a livelooping veteran who used/owned most looping devices on the planet, both hardware and software, still present and out of production.
    I use loopers mostly unsynced for ambient soundscapes and so I was very happy when I learned Everest features feedback! And now, with the knob on the front panel it's even better.

    I have to say though that the knob is kind of difficult to use for me. It's twitchy and the value is hard to read with my finger over it. I personaly would have preferred a fader but I understand the screen-real-estate argument.
    So, I would suggest to borrow a nifty little feature from Mobius which is called "secondary feedback".
    It would mean to add a little button with which you can toggle between two predetermined feedback values. One would (mostly) be 100% and the other what ever is needed to let the loop fade away smoothly while recording another.

    Also borrowing from Mobius, I would suggest to add a knob or fader for latency compensation in the settings. All time-based efx have the possibility to let the effect signal come a little earlier which then could make up for all system hard- and/or software induced latency. People could set the value either by feel or by measurement with a proper latency detection tool.

    My third suggestion would be to add a "kill dry" switch in the settings. When using hardware efx, I often put the looper in a parallel efx loop or in the pre-fader aux bus of a mixer. Then the dry signal gets in the way.

    I've taken a look at your roadmap and I was glad to find pitchshifting on the list of future developments. But I also know from other developers it's kind of hard to implement. What should be much easier to do is the old half speed/octave down feature by halving the sample rate. Would you take it into consideration?

    In closing, I'd like to add one feature to my wishlist of which I'm not sure if it isn't already there...if so, please excuse my not seeing it/understanding the routing and bouncing options properly. :-)
    I would call it cross-feedback. Meaning: once I've created a first loop, I'd like to bleed some of it into the recording of the second loop together with what I play. Then, going back to loop one, some of loop two should bleed into loop one (or another) and so forth. The loops would constantly add to each other until all gets either a giant wall of sound...mess... - well, I like certain amounts of unpredictabilitiy ;-) - or one dials the cross-feedback down, so everything quietens after a while. - Like I said, it's possible that I might be able to do that already with routing or bouncing but I don't see it, yet. If so, please enlighten me. Otherwise, would this feature be interesting?
    It would most certainly be something for the experimentalists, only. But I've already done this with hardware getting some both interesting and surprising results. I know, I could still do this with Everest and 2 aux busses of a mixer but it would be nice if I didn't have to bring one all the time...

    Anyway, so much for now.

    Thanks again for creating such a brilliant music tool and, of course, for your time! :-)


  • Hi Starscape,

    You make a lot of good points... Let me try and address them one-at-a-time:

    1) I totally agree that the feedback knob could be improved. I have the same problems in practice that you are having: a) jumpy values when engaging the touch interface and b) not being able to clearly see the current value with one's finger(s) over the knob. It really is just a matter of me doing some more UI programming to get that right (UI programming takes forever...)

    I have experimented with some kind of feedback stepping, much like the global feedback button. I think this is definitely possible by MIDI if nothing else (running out of button space on the app at the moment!)

    2) Latency compensation has been interesting on iOS. The default latency is very low, but can be changed. I just need to make a display for it. In terms of moving the playing audio backwards from incoming audio (to compensate for hardware latency) I have yet to come up with a solution that makes a big enough improvement... I will re-visit it and see what is possible.

    3) When using Everest in isolation (i.e. NOT audiobus) there shouldn't be any dry signal. In practice I use Everest in a similar fashion to you: Bussed on it's own parallel chain with no dry/direct signal as part of that parallel chain. Is that how you are using Everest in Audiobus? If not, please describe your setup with more specifics so I can understand the request....

    4) I have a prototype of non-time-stretching pitch shifting that is working well. There are few code kinks to iron out (minor) but also a new UI for it (which is a bear).

    5) Bounce will get you close to what you want, but not 100% of the way there: a) it can't change the balance of the bounced "mix", b) it doesn't leave the the originals playing when the bounce finishes, and c) it doesn't record audio input. I made it to effectively "free" up some tracks for more loops, much like the old cassette four tracks.

    Essentially, one way to create your workflow would be to allow the output signals of each loop to re-routed (with faders/pots) _back_ to the inputs of each loop. I don't mind creating an expert mixer page, it is just more UI work, which is time consuming.

    I am very happy you like it! It is always encouraging to see people getting musical use out of it. let me know if you have more suggestions of feedback.
Sign In or Register to comment.