Notifications
Clear all
Topic starter
Outputting to Cubasis on iPad:
Setting the parts to unique pairs of stereo Channels (1,2), (3,4), (5,6), (7,8)... isn't working quite right.
(1,2) either don't work, or (sometimes) send to (3,4) or (5,6).
Always, one of the 4 pairs is not sending.
There are only 4 parts playing, from a Pattern/Sequence.
But they're not sorted as Part 1 is not played. Part 3, by way of example is targeting (or supposed to) USB Channels (1,2)
And the others are Parts 5, 6 and 7.
Is there something wrong with USB Audio out and pairing it with iPad/Cubasis?
Posted : 26/03/2021 4:36 pm
Topic starter
iPad receives as 2 further forward... if there's no outputting on Main LR.
` MODX (1,2) = iPad Cubasis (3,4) `
` MODX (3,2) = iPad Cubasis (5,6) `
` MODX (5,6) = iPad Cubasis (7,8) `
` MODX (7,8) = iPad Cubasis (9,10) `
Posted : 26/03/2021 6:51 pm
Topic starter
lots of Daws handle this the same way. Only Fl Studio recognizes the Main L&R out as separate from the usb pairs. It just shows how much inconsistency there is in the audio tech industry. It needs more standardization. These are areas where things cannot be up to programmers personal preference on how they count and label ports. Im not a programmer so what do I know but numbers should be standard and not have to mix match things to to get them talking. On Bitwig studio I have to set it up just like mentioned about, but i can relabel the ports so they say "1 and 2" even though they are actually "3 and 4"
Posted : 29/03/2021 3:23 pm
This is something MIDI 2.0's capability inquiry can solve. Where the MIDI device self-identifies its own terms and labels for various "components".
So generically, MIDI 1.0 is like the old ISA cards running under DOS - where you had to manually configure interrupts, ports, memory ranges, etc. for each card without any real standard of how to manage these.
Rather than standardizing the ports and memory ranges - what happened is more of the concept of "plug and play" from USB. Where the devices self-identify what their resources/requirements are and the OS or OS+driver handles the rest. In the case of MIDI 2.0 - the "driver" is part of the property exchange inside the MIDI device itself - so each device self-identifies its terms/labels/requirements. This doesn't pin down the industry to use any given ordering for audio/MIDI/CC/etc. which allows for abstracting the lower levels and giving device-matching labels. There wouldn't be a need to care about the order of audio in one DAW vs. another since the device's names would be used in all (that support MIDI 2.0).
Posted : 29/03/2021 4:59 pm
