you can (or should be able to) if you use the auto channel on the external device, then anything doable via the onboard keys/pads is doable externally
Tried using Booth USB and DIN MIDI, I can play the internal synhs when in auto channels, but A4 is not routing the external MIDI input to the external MIDI instrument (I can play it with the internal mini keys)
I agree - itâs not passing Auto Channel MIDI via DIN or USB
itâs now a useful facility given the device can sequence, but can you be confident it once worked or have I(we) assumed it would work
but yeah - a bit surprised that it doesnât offer all the functionality of the onboard keys - it may be unexpected behaviour and a bug, maybe report it then
I tried by setting the output channel to both options too, but it made no difference
It will play the onboard synth fine but wonât share the incoming MIDI forward, as though there was only activity on the mini-keys !
using discrete channels externally doesnât make a difference either fwiw
I know that but it isnât the same, not least because of the amount of work Iâd have to do to set it up. Iâm really not trying to force this on anyone else, just saying I prefer how the Digitone works.
I ticketed this issue for the ARii but flagged as applicable to All analogs
did the same for MKI, thanks!
A4, no midi out from the seq using usb midi. I can configure the incoming midi channels, but there are no midi signals coming through, only when using the minikeys; those work as excepted. Tested with ableton and bitwig.
This is not a bug, you just havenât enabled MIDI out in the Fn+Note menu or you havenât got a setting right somewhere
Itâs been discussed dozens of times in the relevant thread
THANKS, tried to find messages concerning this, but no success.
In the OB Engine my AK is stuck saying âmeasuringâ. Iâve tried everything I can think of (repair install, new USB cable, every available USB portâŚ). It used to work on the old Beta, but now⌠nothing.
lmao obviously the first thing I try when I power up is assigning Quick Perf to all 10 perf knobs
and good lord my a4mkii STRUGGLES. took like 10-20s to catch up with my knob movements, it was stuttering along trying to keep up.
2 seems ok. 3, I can get input lag if I really wiggle the knob. 4 is where it starts to get iffy. 10, a single sweep of the knob causes input/LED lag.
Looks like sequencing/audio still goes smooth, which is good. (aside from the choppiness of the perf macros)
And of course I tried abusing it to see if I could kill the machine. Feels like an overflowing ring buffer; I swear I managed to get it to replay knob movements out of order, or repeat buffered motions more than once. Better than a fatal overflow, i supposeâŚ
this is very silly of course, but holy cow it would be hilarious to sweep 50 parameters with one knob.
Very minor, but it looks like the load project header can bump the cursor/selection off the bottom of the screen. Looks strange, but once you move the cursor itâs good again.
On my A4 MK I with a new project it can only select LFO Trig Mode FRE and HLF.
TRG, HLD and ONE are not displayed.
Has someone the same problem?
Coincidentally the first and last
Are you sure you are not scrolling too fast, works fine here on a new project
Iâll concede it seems faster scrolling somehow, but that may be my mind playing tricks
It certainly doesnât feel nice, you have to scroll far too slowly to see the intervening modes
Ah yes your right itâs really sensitive. Also in the opposite to LFO depth. Thanks!
Yeah noticed this
QPER issue
Typically you start with this, QPER is attached to Macro 1, hold QPER down to see and select
starting state
Firstly if you Press 1 twice you can deselect all assignments, this seems a possibly superfluous state as there is a QPER Mute - I am proposing that it is not intentional, especially if it was intentional then the first press of 1 should deselect it.
starting state then press 1 twice
Secondly, from default starting point, subsequent selections in addition to the existing Macro1 will wipe 1 away
starting state
starting state then press 2 (note 1 is cleared)
my hunch is that this is also unintended behaviour
so e.g. you had this following assignment and you merely wanted to remove one assignment
if you wanted to deselect just 5 in this case so you press it, but you actually get this
it just seems likely that this current behaviour of selection is unintended/bug
Note as an aside that attaching multiple Macros to QPER will make for an increasingly unresponsive interface
my guess is that that assignment logic is intended.
It seems like itâs meant to be âselect a new destinationâ rather than âadjust the current destinationâ. So more similar workflow to selecting a new pattern, than muting/unmuting tracks.
With this logic, assigning to a new single destination still is only 2 keypresses (vs 3 if it toggled like perf track mutes: QPER>old destination>new destination)
I already reported the serious lag with many destinations enabled.
This may be so, we can guess, but it doesnât explain why deselecting all takes pressing the selected one twice - it smacks of unintended behaviour imho, otherwise just treat like a toggle
I can see a case where striating afresh is handy, but it is rather unintuitive, itâs not the end of the world, I only reported on the first issue above the line - the latter issue is just a bit of a surprise, for me