Weeping Wall for iOS

enkaytee

@skiphunt said:

@bygjohn said:

@enkaytee said:
Anyone else noticing that if an AUM session is reloaded, although WW will load with the correct 'saved state' settings the triggering doesn't work? For me, though the audio input crosses the threshold the loops aren't triggered. I need to save the WW settings as an AUM preset then when I reload the session, I have to remove and reload WW and load the previously saved preset for the loops to trigger.

I've emailed Aqeel and he's already responded but wondered if it's just me having the issue...!

Ah, that explains something I’d experienced but not systematically tracked down. I’ve definitely had the visual indicator showing that it should be triggering but it isn’t working.

I’ve noticed the same thing… not always triggering when it should. I think this potential bug occurred with the last update.

I have wondered if it has something to to with the new feature setting called Random Skip. If I’ve set that at all, it seems like the non-triggering issue occurs. It’s almost as if the setting isn’t actually setting a percentage, but applying itself 100% no matter what percentage you’ve selected.

Only vague speculation though

OK - I've never set random skip to anything other than zero - to be honest I'd not even seen it till you mentioned it! Still, could be relevant. I'm passing information to Aqeel and will post here if there are any updates...

skiphunt

@enkaytee said:

@skiphunt said:

@bygjohn said:

@enkaytee said:
Anyone else noticing that if an AUM session is reloaded, although WW will load with the correct 'saved state' settings the triggering doesn't work? For me, though the audio input crosses the threshold the loops aren't triggered. I need to save the WW settings as an AUM preset then when I reload the session, I have to remove and reload WW and load the previously saved preset for the loops to trigger.

I've emailed Aqeel and he's already responded but wondered if it's just me having the issue...!

Ah, that explains something I’d experienced but not systematically tracked down. I’ve definitely had the visual indicator showing that it should be triggering but it isn’t working.

I’ve noticed the same thing… not always triggering when it should. I think this potential bug occurred with the last update.

I have wondered if it has something to to with the new feature setting called Random Skip. If I’ve set that at all, it seems like the non-triggering issue occurs. It’s almost as if the setting isn’t actually setting a percentage, but applying itself 100% no matter what percentage you’ve selected.

Only vague speculation though

OK - I've never set random skip to anything other than zero - to be honest I'd not even seen it till you mentioned it! Still, could be relevant. I'm passing information to Aqeel and will post here if there are any updates...

Edited my previous speculation.. I no longer think it’s related to the random skip setting - could not reproduce

aqeelaadam

Hey y'all, just wanted to pass a quick note that I'm aware of the issue and working on a fix today! Thanks to @enkaytee for providing a bunch of very helpful info.

Btw, definitely not related to Random Skip - that would only apply after a loop is actually recorded.

aqeelaadam

Sorted out the issue and pushing a fix to the App Store today! It should rollout in the next day or so when it gets approved, which is usually pretty speedy.

For anybody who's curious about the nitty-gritty, WW disables recording for a couple seconds after pausing (either via the transport control or via the live performance mode). This is to prevent a weird situation where the user might stop the transport, for example, but a sound that's ringing out might trigger a new recording, which would be confusing given that you just paused everything and WW should shut up. The main issue was that WW was disabling recording after startup, as if it had just been paused. This compounded into an unexpected loop where recording wouldn't re-enable if WW received sound during this period, so really it was a timing loop where feeding WW too soon would cause it to disable recording for an unexpected amount of time.

bygjohn

@aqeelaadam said:
Sorted out the issue and pushing a fix to the App Store today! It should rollout in the next day or so when it gets approved, which is usually pretty speedy.

For anybody who's curious about the nitty-gritty, WW disables recording for a couple seconds after pausing (either via the transport control or via the live performance mode). This is to prevent a weird situation where the user might stop the transport, for example, but a sound that's ringing out might trigger a new recording, which would be confusing given that you just paused everything and WW should shut up. The main issue was that WW was disabling recording after startup, as if it had just been paused. This compounded into an unexpected loop where recording wouldn't re-enable if WW received sound during this period, so really it was a timing loop where feeding WW too soon would cause it to disable recording for an unexpected amount of time.

Wow, that was fast! Thank you for getting on the case and sorting it out so quickly!

aqeelaadam

My pleasure! Most bugs end up being simple and dumb mistakes on my part. I find it's better to just fix them rather than let them accumulate

KMTGN

It would be great to have an input signal pan control. and on gauss looper too

bygjohn

@KMTGN said:
It would be great to have an input signal pan control. and on gauss looper too

If you’re using it in AUM, you could use the AUM panner node or an auto panner like Panflow before it.

aqeelaadam

@bygjohn said:

@KMTGN said:
It would be great to have an input signal pan control. and on gauss looper too

If you’re using it in AUM, you could use the AUM panner node or an auto panner like Panflow before it.

This would be my friendly suggestion as well There are a ton of great tools out there already that can produce a fun combo with Weeping Wall, and I don't want to overcomplicate the app too much.