I've loaded Zeeon, Ruismaker FM, and Model 15 on the first three pads of a bank, but I'm not getting any crashes when tapping the keyboard on the left pane. perhaps there's more to this crash? I'm on a 2015 ipad pro with ios 11.1. I DO have some weird performance issues with the mini keyboard at the bottom of the screen in the sampler/edit screen, kinda like a quantization delay, but white keys have more delay issues then black keys. white keys don't even appear to be pressed until the sound triggers after a very noticeable delay. that said, the full size keyboard does not have this issue at all, and I can deal with a delay when I'm just previewing sounds in the sampler/edit screen.
@ronji said:
I DO have some weird performance issues with the mini keyboard at the bottom of the screen in the sampler/edit screen, kinda like a quantization delay, but white keys have more delay issues then black keys. white keys don't even appear to be pressed until the sound triggers after a very noticeable delay.
Finally someone else who bumped into this!!!
Is the trigger mode of the sample set to 'hold'?(I'm trying to narrow down what causes this).
If the trigger mode is set to 'One Shot' there is no lag but if it's set to 'Hold' the lag is present?
If you swipe your finger across multiple keys there should be no lag?
Also if you 'swipe tap' the key it should trigger properly?
I suspect this is related to the 'tap and hold' behaviour and the bug appeared after the left and right arrows where added to the mini-keys used in the sample edit page.
I have reported the behaviour to @mathieugarcia with an accompanying video showing the 'lag'.
@samu well done, it's just like you describe! note I noticed this first with AU instruments, not samples, so I don't know if it has anything specifically to do with the hold setting, but obviously keyboard instruments like Zeeon and Model 15 generally work like that. I loaded a sample into a pad to confirm it works fine when one-shot is set, and acts us when hold is set.
@ronji said: @samu well done, it's just like you describe! note I noticed this first with AU instruments, not samples, so I don't know if it has anything specifically to do with the hold setting, but obviously keyboard instruments like Zeeon and Model 15 generally work like that. I loaded a sample into a pad to confirm it works fine when one-shot is set, and acts us when hold is set.
Goodie, another 'thing' that is still broken is the right-side piano in the pattern editor.
It no longer plays/previews any notes.(Reported during 3.0.4 beta).
There's also a semi-annoying bug with the note-draw tool (3rd tool from the left).
It remembers the length when a new note is drawn but if the length is adjusted it doesn't remember the change and defaults to grid-size (Also reported during beta...).
So yah, lots of things get caught and reported during testing but I don't know what criteria a bug has to meet to get priority
thanks for the heads up, @samu! regarding the AU problems mentioned on this thread, it does seem to be something related to pre 3.0.4 sessions. I opened my battle 02 session, and while Addictive Pro properly played the sounds with the pad and keys, but trying to open the AU UI crashes bm3.
update: if you load another instance of the AU, in that same pre 3.0.4 session, it won't crash when you open the AU UI, but the old instance of the AU will still crash bm3. copying the pad with the old instance or resaving the session don't help the issue.
@ronji said:
thanks for the heads up, @samu! regarding the AU problems mentioned on this thread, it does seem to be something related to pre 3.0.4 sessions. I opened my battle 02 session, and while Addictive Pro properly played the sounds with the pad and keys, but trying to open the AU UI crashes bm3.
update: if you load another instance of the AU, in that same pre 3.0.4 session, it won't crash when you open the AU UI, but the old instance of the AU will still crash bm3. copying the pad with the old instance or resaving the session don't help the issue.
There's a LOT of different factors at play when it comes to AUv3 stability. Some are caused by iOS bugs(memory management among other things). I always keep my iOS devices up to date (iOS11.1, Air 2 at the moment) since I know there will be no updates for older iOS systems to fix those kind of bugs.
As for AUv3 usage I mostly use them as 'sampler fodder' and seldom use multiple instances at the same time.
I have noticed though that AUv3's built using ROLI's JUCE framework seem to be more unstable than others...
@samu I agree there seems to be a lot of issues around AUv3 still, but in this case it's a bit unexpected. if you had a session you were working on in 3.0.3 and you had Zeeon set up with a patch you may not have finished tweaking, and you updated to 3.0.4, you can no longer open the AU UI to tweak that patch anymore, as bm3 will just crash. a bit unfortunate, and unexpected, even on the latest ios 11.1. =( thankfully this doesn't affect me so much, as I don't much intend to work on the AUs in my old sessions, but now I will do my best to make sure any patch modifications get saved if I really love them!
Agreed. 'Compatibility' between versions is something that should be valued by the developers.
I mean if there are major 'fixes' the older sessions should be 'updated' and 'verified' before being opened to avoid crashes. Like if new parameters are added to the sampler the older sessions should be updated to accommodate those additions. (Like being able to adjust the fine-tuning individual samples on one layer which is a no can do at the moment).
I use AUs in every one of my sessions, and I'm beginning to worry that I won't be able to work on any of my 3.0.3 (or earlier) sessions now unless I go through the process of unloading/reloading every AU in all of them and then try to recreate all the patches from memory.
I've read @mathieugarcia 's apology and post about the random sound pack causing the 3.0.4 crashes, but it sounds like they've rapid-released 3.0.5 without realising there is this other massive bug.
For those who use AB forums, are they also discussing the AU UI bug mentioned in this thread?... Cos it seems @mathieugarcia likes to hang out there more than here
@ronji I found the reason behind the 'laggy keys' it's caused by the iOS Dock and it's 'swipe up zone'.
If i press the upper half of the mini keys they work as expected while the lover half doesn't work properly.
If you tap the lower half and swipe up the dock comes up.
The 'Dock Swipe' can NOT be disabled in iOS11
It's not only the mini keys that are affected, all keys that reach the bottom of the screen are affected when tapping them in the 'dock swipe zone'.
@samu said: @ronji I found the reason behind the 'laggy keys' it's caused by the iOS Dock and it's 'swipe up zone'.
If i press the upper half of the mini keys they work as expected while the lover half doesn't work properly.
If you tap the lower half and swipe up the dock comes up.
The 'Dock Swipe' can NOT be disabled in iOS11
It's not only the mini keys that are affected, all keys that reach the bottom of the screen are affected when tapping them in the 'dock swipe zone'.
Previous version worked well, maybe has to be something with the added dragging support?
gah! well that explains why the black keys aren't much affected by the issue
I want an option to disable the dock swipe gesture. you can get around the functionality using the home button, anyway. Apple should allow it to be configured per app, at least.
@ronji said:
gah! well that explains why the black keys aren't much affected by the issue
I want an option to disable the dock swipe gesture. you can get around the functionality using the home button, anyway. Apple should allow it to be configured per app, at least.
There are plenty of music apps on iOS that are affected by this 'issue'.
Some apps like Cubasis, and Poison-202 are NOT affected by this while the likes of PhaseMaker, Zeeon and BM3 are...
The only difference I've seen is that those apps that are NOT affected bring up a small arrow at the bottom of the screen when swiped up and the 'affected' apps bring up the dock directly...
So this is something developers will have to tackle on iOS11 to keep their apps responsive.
Also it's not possible to globally disable the 'swipe up' gesture as it's not part of the 'gesture set' or 'multiple apps' settings.
I've forward my findings to Mathieu already so we're on this so it will be fixed in due time
@samu ah! so it should be something that intua can implement to prevent that from happening! I think bm3 also suffers from this same issue on controls at far right of the screen, and maybe at top of the screen. if you pull in from any of these sides, the dock or the notification screen or a slide-over app that's been slid out will immediately come on screen. maybe this is also what @Artmuzz is talking about and what you mentioned earlier. if I tap a bit further in from the far right edge of the screen, I can play notes in the piano roll editor. similarly, if you hold at the edge of the screen or if you tap and slide up or down at the edge of the screen you'll hear the notes. this might be easier for me to deal with on my 12.9" screen. but @Artmuzz if you're talking about the piano keys on the left side of the piano roll editor, those don't make sound. you can simply scroll up and down or pinch zoom on the "large" keys but you can play notes with the small keys at far right, if you're not too close to the edge of the screen in ios 11
@ronji said: @samu ah! so it should be something that intua can implement to prevent that from happening! I think bm3 also suffers from this same issue on controls at far right of the screen, and maybe at top of the screen. if you pull in from any of these sides, the dock or the notification screen or a slide-over app that's been slid out will immediately come on screen. maybe this is also what @Artmuzz is talking about and what you mentioned earlier. if I tap a bit further in from the far right edge of the screen, I can play notes in the piano roll editor. similarly, if you hold at the edge of the screen or if you tap and slide up or down at the edge of the screen you'll hear the notes. this might be easier for me to deal with on my 12.9" screen. but @Artmuzz if you're talking about the piano keys on the left side of the piano roll editor, those don't make sound. you can simply scroll up and down or pinch zoom on the "large" keys but you can play notes with the small keys at far right, if you're not too close to the edge of the screen in ios 11
It's the smaller keys on the piano roll keyboard running down the right side of the screen which don't make any sound when it should. On BM 3.0.3 and earlier the keyboard always played sounds when playing notes but now on 3.0.4 they don't make any sound now. Hopefully this is just a bug which will be fixed.
Comments
Removed
From Intua Twitter:
“Everything’s under control now, it should work even without the airplane mode trick now. Just an issue with the soundstore”
—
20+ mins ago..
—
King
..
Yeah. Thanks. Just seen that on Twitter.
It’s still an issue. Crash when selecting keyboard from left hand menu for au’s In this case Model 15 and Ruismaker.
Yep! I’m back n forth between here, there and other forums.
Not updating till it’s all clear, sure it will be soon..
—
King
..
aU s crashing bm3 when selected. DO NOT UPDATE
I just lost 20 mins work.
The only fix was to unload Zeeon then reload it (losing my custom patch
I've loaded Zeeon, Ruismaker FM, and Model 15 on the first three pads of a bank, but I'm not getting any crashes when tapping the keyboard on the left pane. perhaps there's more to this crash? I'm on a 2015 ipad pro with ios 11.1. I DO have some weird performance issues with the mini keyboard at the bottom of the screen in the sampler/edit screen, kinda like a quantization delay, but white keys have more delay issues then black keys. white keys don't even appear to be pressed until the sound triggers after a very noticeable delay. that said, the full size keyboard does not have this issue at all, and I can deal with a delay when I'm just previewing sounds in the sampler/edit screen.
Finally someone else who bumped into this!!!
Is the trigger mode of the sample set to 'hold'?(I'm trying to narrow down what causes this).
If the trigger mode is set to 'One Shot' there is no lag but if it's set to 'Hold' the lag is present?
If you swipe your finger across multiple keys there should be no lag?
Also if you 'swipe tap' the key it should trigger properly?
I suspect this is related to the 'tap and hold' behaviour and the bug appeared after the left and right arrows where added to the mini-keys used in the sample edit page.
I have reported the behaviour to @mathieugarcia with an accompanying video showing the 'lag'.
Yep can confirm both bugs too on iPad pro 10”. The mini keyboard now doesnt works properly.
Also my forum account was deleted... ¿?
@samu well done, it's just like you describe! note I noticed this first with AU instruments, not samples, so I don't know if it has anything specifically to do with the hold setting, but obviously keyboard instruments like Zeeon and Model 15 generally work like that. I loaded a sample into a pad to confirm it works fine when one-shot is set, and acts us when hold is set.
Goodie, another 'thing' that is still broken is the right-side piano in the pattern editor.
It no longer plays/previews any notes.(Reported during 3.0.4 beta).
There's also a semi-annoying bug with the note-draw tool (3rd tool from the left).
It remembers the length when a new note is drawn but if the length is adjusted it doesn't remember the change and defaults to grid-size (Also reported during beta...).
So yah, lots of things get caught and reported during testing but I don't know what criteria a bug has to meet to get priority
thanks for the heads up, @samu! regarding the AU problems mentioned on this thread, it does seem to be something related to pre 3.0.4 sessions. I opened my battle 02 session, and while Addictive Pro properly played the sounds with the pad and keys, but trying to open the AU UI crashes bm3.
update: if you load another instance of the AU, in that same pre 3.0.4 session, it won't crash when you open the AU UI, but the old instance of the AU will still crash bm3. copying the pad with the old instance or resaving the session don't help the issue.
There's a LOT of different factors at play when it comes to AUv3 stability. Some are caused by iOS bugs(memory management among other things). I always keep my iOS devices up to date (iOS11.1, Air 2 at the moment) since I know there will be no updates for older iOS systems to fix those kind of bugs.
As for AUv3 usage I mostly use them as 'sampler fodder' and seldom use multiple instances at the same time.
I have noticed though that AUv3's built using ROLI's JUCE framework seem to be more unstable than others...
@samu I agree there seems to be a lot of issues around AUv3 still, but in this case it's a bit unexpected. if you had a session you were working on in 3.0.3 and you had Zeeon set up with a patch you may not have finished tweaking, and you updated to 3.0.4, you can no longer open the AU UI to tweak that patch anymore, as bm3 will just crash. a bit unfortunate, and unexpected, even on the latest ios 11.1. =( thankfully this doesn't affect me so much, as I don't much intend to work on the AUs in my old sessions, but now I will do my best to make sure any patch modifications get saved if I really love them!
Agreed. 'Compatibility' between versions is something that should be valued by the developers.
I mean if there are major 'fixes' the older sessions should be 'updated' and 'verified' before being opened to avoid crashes. Like if new parameters are added to the sampler the older sessions should be updated to accommodate those additions. (Like being able to adjust the fine-tuning individual samples on one layer which is a no can do at the moment).
I've read @mathieugarcia 's apology and post about the random sound pack causing the 3.0.4 crashes, but it sounds like they've rapid-released 3.0.5 without realising there is this other massive bug.
For those who use AB forums, are they also discussing the AU UI bug mentioned in this thread?... Cos it seems @mathieugarcia likes to hang out there more than here
Yeah the other bugs were not fully mentioned as fixed but hopefully they are.
---
King
..
@ronji I found the reason behind the 'laggy keys' it's caused by the iOS Dock and it's 'swipe up zone'.
If i press the upper half of the mini keys they work as expected while the lover half doesn't work properly.
If you tap the lower half and swipe up the dock comes up.
The 'Dock Swipe' can NOT be disabled in iOS11
It's not only the mini keys that are affected, all keys that reach the bottom of the screen are affected when tapping them in the 'dock swipe zone'.
Previous version worked well, maybe has to be something with the added dragging support?
gah! well that explains why the black keys aren't much affected by the issue
I want an option to disable the dock swipe gesture. you can get around the functionality using the home button, anyway. Apple should allow it to be configured per app, at least.
There are plenty of music apps on iOS that are affected by this 'issue'.
Some apps like Cubasis, and Poison-202 are NOT affected by this while the likes of PhaseMaker, Zeeon and BM3 are...
The only difference I've seen is that those apps that are NOT affected bring up a small arrow at the bottom of the screen when swiped up and the 'affected' apps bring up the dock directly...
So this is something developers will have to tackle on iOS11 to keep their apps responsive.
Also it's not possible to globally disable the 'swipe up' gesture as it's not part of the 'gesture set' or 'multiple apps' settings.
I've forward my findings to Mathieu already so we're on this so it will be fixed in due time
I've noticed there is no sound when playing notes on the piano roll keyboard in pattern mode. Is this another bug of BM 3.0.4
Saw this ^ mentioned 'somewhere' earlier..
I haven’t updated to 3.0.4 so can’t test anything, but your not alone on that one.
King
..
@samu ah! so it should be something that intua can implement to prevent that from happening! I think bm3 also suffers from this same issue on controls at far right of the screen, and maybe at top of the screen. if you pull in from any of these sides, the dock or the notification screen or a slide-over app that's been slid out will immediately come on screen. maybe this is also what @Artmuzz is talking about and what you mentioned earlier. if I tap a bit further in from the far right edge of the screen, I can play notes in the piano roll editor. similarly, if you hold at the edge of the screen or if you tap and slide up or down at the edge of the screen you'll hear the notes. this might be easier for me to deal with on my 12.9" screen. but @Artmuzz if you're talking about the piano keys on the left side of the piano roll editor, those don't make sound. you can simply scroll up and down or pinch zoom on the "large" keys but you can play notes with the small keys at far right, if you're not too close to the edge of the screen in ios 11
It's the smaller keys on the piano roll keyboard running down the right side of the screen which don't make any sound when it should. On BM 3.0.3 and earlier the keyboard always played sounds when playing notes but now on 3.0.4 they don't make any sound now. Hopefully this is just a bug which will be fixed.
My bad, I was definitely testing the piano roll with audio, not AU. You’re right, no sound from the keys in piano roll for AUv3.
I think possibly these thread comments etc could be individualised, new threads/bug reports etc..
Not for me, but easier for the developers..
King
..
A little bit of calm could help too haha, i will be surprised if you have lost 3.0.3 songs completely, they will fix have to fix it.
No sound from keys in piano roll for samples either.
AUv3 fullscreen keyboard crash fixed in 3.0.5 (currently under review).