Post your great Auxy feature idea here!


We don’t try to hide the fact that Auxy isn’t in any way optimized for people who want to make expressive piano pieces. So this reasoning is still very theoretical.


I can’t speak to the conspiracy theories, but tbh, it’s a little difficult to stay entirely positive in the feedback when that seemingly requires giving you – someone who does (or at least should) know better – the benefit of the doubt – every time.

If the app’s not what I need, then indeed, I can either continue to sub or walk away.
But, it would be a particular shortcoming if users were to reach that tipping point due to avoidable uncertainty and frustration caused by poor communication from the Auxy team.

Talk is literally cheap. When it comes to B2C comms, that’s a good thing. :wink:


An observation…

Quite a few of your responses seem a little like dodges or attempts to deflect.

You respond (indirectly) to a request/criticism about supporting user tags when uploading to SC by pointing at how bad the SC app is.
(If the SC upload API only supports a single tag, then that’s your legitimate reason [although you should probably allow the user to specify the tag]. The fact that an SC app that’s clearly not aimed at producers doesn’t support producer-centric features is irrelevant.)

You respond (indirectly) to a request for permanent local caching of favourited assets by first pointing at how poor iCloud can be. Sure, that may be a major reason, but don’t lead your response with it.

You respond (indirectly) to a request/criticism about your responsiveness on this channel by stating how diligently you attend to another of your comms channels.

It feels kinda evasive as though the feedback/criticism isn’t valid, and in being so, disrespectful. Why not just address the input directly rather than trying to deflect?

Upload To Spotify For Free?

Sure, the legitimate reason is that a) it’s possible but not important enough for us right now, and b) it’s generally a bad idea to work on building out features that should, and likely will, be a part of the third party’s responsibilities. I.e. let’s wait a couple of months and this will probably be solved in either way.

Upload To Spotify For Free?

I think the opaqueness on what activity is taking place feeds the uncertainty of which features you are actually working on.
Yes, it’s relatively niche, but it’s unclear that you’re not working on X because you’re working on [insert more popular/useful feature] instead because you’re very opaque about which proposed features you’re pushing ahead with.

(I would hope that you’re not pulling feature ideas out of the air without first gauging how in-demand it might be – especially when you have an audience right here to bounce ideas off of ahead of any development prioritisation.
I’m still curious to know how the glossy redesign of the scene lengths/offsets became an imperative.)


My intention was to point at how bad of a decision it was from our side to use iCloud in general and that we have to do something about it so that we can resolve these types of issues. We might be able to resolve this regardless, so stay tuned for the next update.


The comment was that we should always maintain an open channel to our paying customers, and my respons was an attempt to reassure everyone that we do that.


I’m addressing input but the responses I get from certain people makes me less inclined to put my heart into the conversations, to put it mildly. Trying to address that though in hopes of changing the vibe here.


Maybe I’m missing something, but…

Either the API can support adding multiple tags during upload – or it doesn’t.
Which is it?

If it doesn’t, then your response should be about the limitations of the SC API.

If it is, then what reason do you have to expect it will be fixed in the coming months?

Either way, the SC app itself has nothing to do with it. As mentioned, it’s not aimed at producers/uploaders, but listeners.

If the wait also means you’ll be addressing it in the coming months, then why be so obtuse/cryptic?
Why not simply say ‘We’re working on and it’ll be in an update in the next couple of months’.


Don’t need your heart – just your business brain. :wink:


It’s possible but not a priority for us right now. It might be in the future. But we don’t plan product releases that way. Perhaps that’s worth stating here, so that you don’t think the lack of clear responses is just because I’m taking a piss with everyone. If we’re fixing something, I will of course say that.


NOW YOU’RE SPEAKING MY LINGO. For every time I used tempo automation I can think of at least 50 times (or more) I used a loop or part of a loop.


I feel like having iCloud in the mix here is actually a strength. It couldn’t be easier to switch between devices, plus I’m comforted knowing all my projects and samples are tied to my iCloud storage rather than having to manually back up all my stuff using a computer (looking at you, Gadget…)


Further to support for loops… this is an area where Medly does shine (trying to compare apples to apples here) - proper files app integration, imported loops can be re-keyed and re-tempo’d via some sort of stretch algorithm similar to Blocs Wave. If we could skip that export step it’d be pretty sweet. I understand this is not an easy task, much easier on paper. For now I’d be satisfied with 10-20 seconds of audio import. The workarounds work but there’s nothing worse than dumping something out of Blocs Wave and it’s 11 seconds long :skull_and_crossbones:


iCloud is great in theory but far from perfect in practice.


Right but if we set the limit to 12 secs than surely you will have some loops that are 13 secs etc.? :slight_smile:


You’re right, I don’t disagree. And now that I’ve seen what happens in GarageBand with multiple longer loops (and I’m not even talking long long, like maybe three/four 15-20 seconds a pop) you start to get the optimizing performance pop up. I’m not entirely sure what it’s doing under the hood. Then again Gadget keeps up just fine under the same circumstances so I don’t know…


This isn’t really my game, but 16 seconds is nice sweet spot. That’s 8 bars at 120 bpm if I recall.


But we don’t plan product releases that way.

And how’s working out for you, so far?

‘Long waits and big reveals’ can be satisfying, but maybe how you plan product releases could benefit from reviewing? (Tbf, the current approach seems to attract some significant problems, certainly from an optics perspective.)

Perhaps a shorter release cycle biting off smaller chunks of the backlog - at least, biting off a few of the low hanging fruit and releasing the major feature updates under the current schedule?
(Rapid iteration is kinda the dev/release model these days.)

A track duration counter in the scenes bar, for example. Tap tempo, too (Nudge, nudge)

Would certainly increase the sense of the app’s activity, vitality and momentum amongst users.

Just a thought.

(After the initial failed attempt to fix a newly introduced bug, it’s mortifying that the [real] fix for the Chromatic scale setting bug has had to wait for the next major release slot - assuming it’ll be fixed in the coming update. How many months is it since that bug was first reported? How many months since your last attempt to fix it?)


I think the disconnect we’re having here is that you (seemingly) believe that an open email communication is a substitute for proactively keeping in touch with (and at the very least not temporarily deserting) your consumer base.

From a customer’s perspective, it’s rather unsettling to have the head of development and PR leave the scene for a couple months without any sort of warning and then slip back into everything without any shape or form of explanation.

What do you think that does to people’s confidence in not only you but the app as a whole? Do you think that quickly replying to emails when you are around will mitigate those effects?