Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Drambo is an AU host now / the new Drambo mega thread

1555658606164

Comments

  • @AlmostAnonymous said:

    @rs2000 said:
    @AlmostAnonymous Yes, use the MIDI => MIDI Output module.

    Doesnt that only select channels 1-16 on the midi port (usb), not DAW?
    I need to separate sending midi to it via DAW and USBmidi.

    You'd have to choose the "DAW port" as a MIDI destination of course.

  • edited June 2021

    Holy crap im blind. Im gonna sulk away in utter embarrasment now.....

  • Is Drambo user requested pattern change quantisation (by tap or midi learn) fixed to 1 bar?
    Can that be changed? For example can I set 0 quantisation for instant pattern change?
    Drum Computer seems to be instant pattern change but keeps beat position.

  • @soundtemple said:
    Is Drambo user requested pattern change quantisation (by tap or midi learn) fixed to 1 bar?
    Can that be changed? For example can I set 0 quantisation for instant pattern change?
    Drum Computer seems to be instant pattern change but keeps beat position.

    Have a look in settings for
    ‘Instant pattern switch’
    When switched off it waits until
    the end of the pattern to change.
    When on, it instantly switches pattern
    keeping beat position using either
    the screen or a midi controller.

  • @Gravitas thanks. Must be going blind I was surely looking straight at that setting!!!

  • @soundtemple said:
    @Gravitas thanks. Must be going blind I was surely looking straight at that setting!!!

    No worries. 😏

  • @Owgill said:
    Can Drambo’s arp functionally replicate Expressive e Osomose’s MPE arp? I have a Linnstrument and would like to see if that could be at all possible. There is an interesting video regarding the MPE arp on expressive e’s site. Thx

    A bit off topic but You have the expressive arp built in in the Linnstrument. Have you tried?

  • Hi!
    There’s a little thing that bugs me with the Sampler.
    If you’re transposing a note, the sampler shows the right note when minimized, but it shows the original note when maximized.
    So if I’m hitting C2 and transposing by 4 it plays E2. Shows E2 on the module when minefield but shows the original C2 when maximized (even though you actually hear E2). I believe this is a bug.

  • @tahiche Yes, it was reported already but maybe forgotten in the huge feature factory ;)
    Time for a reminder. I'll do it.

  • edited July 2021

    @rs2000 @bcrichards Thanks in advance for allowing me to ping you, but for the life of me, I cannot figure out how to record the Chords coming out of ChordJam which are driving SynthMaster2 in this setup, to be recorded to the sequencer in Drambo.

    Any thoughts on how to get those ChordJam generated notes which are sequenced or played manually, recorded to the Drambo sequencer in this type of setup?

    Or is this still something I will have to do with Drambo being hosted by AUM, and use the routing of AUM to get my notes into Drambo?

    I hope this question makes sense :) Many thanks!

    Here's a screenshot of what I have setup currently.

  • @echoopera host Chordjam in AUM or Audiobus. You can choose to record into an AUV3 instance of Drambo, but you can also point the AUM or Audiobus hosted Chordjam at standalone Drambo.

    @rs2000 could FreEWI be used here for loopback?

  • edited July 2021

    @bcrichards said:
    @echoopera host Chordjam in AUM or Audiobus. You can choose to record into an AUV3 instance of Drambo, but you can also point the AUM or Audiobus hosted Chordjam at standalone Drambo.

    Thank you for the quick reply. I was trying to avoid this extra step...but it's not a big deal. I'll go the AUM route since I am comfortable with the workflow.

    @rs2000 could FreEWI be used here for loopback?

    FreeWilly what? What is this :)
    https://forum.audiob.us/uploads/editor/uq/3c5nb592k2c1.png

    The movie poster is a metaphor for doing all midi routing and recording in Drambo fwiw :wink:

  • edited July 2021

    @echoopera said:

    @bcrichards said:
    @echoopera host Chordjam in AUM or Audiobus. You can choose to record into an AUV3 instance of Drambo, but you can also point the AUM or Audiobus hosted Chordjam at standalone Drambo.

    Thank you for the quick reply. I was trying to avoid this extra step...but it's not a big deal. I'll go the AUM route since I am comfortable with the workflow.

    @rs2000 could FreEWI be used here for loopback?

    FreeWilly what? What is this :)
    [ ]

    The movie poster is a metaphor for doing all midi routing and recording in Drambo fwiw :wink:

    Yep, you still need an external app for mirroring MIDI back to Drambo until @giku_beepstreet adds internal MIDI routing.
    FreEWI (yes Mr delay orchestra, search for this string 🙏🏼) will do, or another standalone app like MidiFire.
    AUM and ApeMatrix are more options if you''re OK with running Drambo an an AUv3.

    Add a MIDI Out module with destination = FreEWI, keep the free Willy swimming in the underground and magic D will receive the delightful, fresh MIDI stream.

  • edited July 2021

    @bcrichards @rs2000 You know what...in this set up I was being overly complicated. Since ChordJam can receive Midi, all I have to do is enter my Single Note on the Sequencer in Drambo, and the Chord will play the instrument....no need to record the Chord to the timeline...you just need to Enter the single Note, C2, E2, G2...etc and ChordJam will play the corresponding Chord based on the mapping you've set up in the app.

    GENIUS!!! :)

    Cheers!

  • Good to hear @echoopera.
    Anyway - the Drambo MIDI routing question pops up regularly so there seems to be some valid interest in a solution.

    Cheers 😊

  • @rs2000 said:
    Good to hear @echoopera.
    Anyway - the Drambo MIDI routing question pops up regularly so there seems to be some valid interest in a solution.

    Cheers 😊

    No doubt no doubt no doubt :) Onwards and Upwards :wink:

  • I have Drambo loaded up in AUM for a live set I'm working on. I'm using AUMs preset change function to switch between the various synth presets I'm using in various tracks. Unfortunately, Drambo is frequently crashing when receiving those program changes. I'm rocking a new Air 4, and the only other things loaded up in the session are Mozaic and DRC. Any ideas on what I can do to try and alleviate this? It's obviously messing with the part changes in my tracks.

  • edited September 2021

    I am experiencing high DSP usage in DRambo as AUv3 hosted inside AUM, with the MIDI Monitor. I use 8 LFO MIDI CC Generator (one on each channel) and at the end of each channel is inserted an instance of the MIDI Monitor.

    The diference in DSP usage in AUM between the same patches with the MIDI Monitors placed on a channel and with the MIDI Monitors removed is between 15 and 20% and this increase in DSP usage happens every time I open the dRambo AUv3 window containing the project with the MIDI Monitors. It seems that those Monitors are consuming too much CPU, much more than some dRambo’s own audio generators and fx and much more than some complex patches I use.

    This increase in DSP usage even causes Audio glitches if total DSP reaches 100% in AUM.

    So, just by open drambo AUv3 window audio glithes can happen, on patches with MIDI Monitors.

    IPad 8 with 48kHz and 512 samples buffer size. iPadOS 14.8 (happened also in 14.4 I was using before)

  • @andrevjunqueira said:
    I am experiencing high DSP usage in DRambo as AUv3 hosted inside AUM, with the MIDI Monitor. I use 8 LFO MIDI CC Generator (one on each channel) and at the end of each channel is inserted an instance of the MIDI Monitor.

    The diference in DSP usage in AUM between the same patches with the MIDI Monitors placed on a channel and with the MIDI Monitors removed is between 15 and 20% and this increase in DSP usage happens every time I open the dRambo AUv3 window containing the project with the MIDI Monitors. It seems that those Monitors are consuming too much CPU, much more than some dRambo’s own audio generators and fx and much more than some complex patches I use.

    This increase in DSP usage even causes Audio glithces if total DSP reaches 100% in AUM.

    So, just by open drambo AUv3 window audio glithes can happen, on patches win MIDI Monitors

    IPad 8 with 48kHz and 512 samples buffer size.

    I suggest cross-posting this on the Beepstreet forum. It'll get more attention there.

  • @wim said:

    @andrevjunqueira said:
    I am experiencing high DSP usage in DRambo as AUv3 hosted inside AUM, with the MIDI Monitor. I use 8 LFO MIDI CC Generator (one on each channel) and at the end of each channel is inserted an instance of the MIDI Monitor.

    The diference in DSP usage in AUM between the same patches with the MIDI Monitors placed on a channel and with the MIDI Monitors removed is between 15 and 20% and this increase in DSP usage happens every time I open the dRambo AUv3 window containing the project with the MIDI Monitors. It seems that those Monitors are consuming too much CPU, much more than some dRambo’s own audio generators and fx and much more than some complex patches I use.

    This increase in DSP usage even causes Audio glithces if total DSP reaches 100% in AUM.

    So, just by open drambo AUv3 window audio glithes can happen, on patches win MIDI Monitors

    IPad 8 with 48kHz and 512 samples buffer size.

    I suggest cross-posting this on the Beepstreet forum. It'll get more attention there.

    Just tested it my end.
    Reported.

  • @wim said:

    @andrevjunqueira said:
    I am experiencing high DSP usage in DRambo as AUv3 hosted inside AUM, with the MIDI Monitor. I use 8 LFO MIDI CC Generator (one on each channel) and at the end of each channel is inserted an instance of the MIDI Monitor.

    The diference in DSP usage in AUM between the same patches with the MIDI Monitors placed on a channel and with the MIDI Monitors removed is between 15 and 20% and this increase in DSP usage happens every time I open the dRambo AUv3 window containing the project with the MIDI Monitors. It seems that those Monitors are consuming too much CPU, much more than some dRambo’s own audio generators and fx and much more than some complex patches I use.

    This increase in DSP usage even causes Audio glithces if total DSP reaches 100% in AUM.

    So, just by open drambo AUv3 window audio glithes can happen, on patches win MIDI Monitors

    IPad 8 with 48kHz and 512 samples buffer size.

    I suggest cross-posting this on the Beepstreet forum. It'll get more attention there.

    Thanks! I did it just now.

  • @andrevjunqueira said:
    I am experiencing high DSP usage in DRambo as AUv3 hosted inside AUM, with the MIDI Monitor. I use 8 LFO MIDI CC Generator (one on each channel) and at the end of each channel is inserted an instance of the MIDI Monitor.

    The diference in DSP usage in AUM between the same patches with the MIDI Monitors placed on a channel and with the MIDI Monitors removed is between 15 and 20% and this increase in DSP usage happens every time I open the dRambo AUv3 window containing the project with the MIDI Monitors. It seems that those Monitors are consuming too much CPU, much more than some dRambo’s own audio generators and fx and much more than some complex patches I use.

    This increase in DSP usage even causes Audio glithces if total DSP reaches 100% in AUM.

    So, just by open drambo AUv3 window audio glithes can happen, on patches win MIDI Monitors

    IPad 8 with 48kHz and 512 samples buffer size.

    Just a couple of suggestions. First, the MIDI CC Generator sends a new CC message whenever the input value changes, even if the CC value is unchanged (at least it used to). This creates a lot of duplicate outputs, and makes the MIDI Monitors very busy. If you quantize the CV values to 128 levels before sending to the CC Generator, you can prevent this, without changing the actual result.

    Second, updating the MIDI Monitors requires steadily refreshing the Drambo window, adding a heavy graphics load. So it's not surprising that they affect the results. Remember, the "DSP" measures the total system load, not the time specifically used for audio signal processing.

  • edited September 2021

    Like uncledave mentioned CC generator does not round values to midi resolution. This was reported, and had been fixed in current beta. Most likely this is causing cpu overload (too many midi messages).
    However CC generator (multi) should be working fine (rounding to midi resolution), and you can achieve the same using that, until update drops.

  • edited September 2021

    Just tested CC gen (multi) with 8 LFOs in AUM 48k @256 ~25% on Air3.

    CPU goes even lower using midi monitor module inside Drambo.

  • @0tolerance4silence said:
    Just tested CC gen (multi) with 8 LFOs in AUM 48k @256 ~25% on Air3.

    Try them on separate 'Tracks' with individual midi outs per 'Track'.

  • @Gravitas said:
    Try them on separate 'Tracks' with individual midi outs per 'Track'.

    More or less the same...
    Each track with an LFO modulating CC gen (multi) and sending out midi to AUM + midi monitor module on each track

    Without MIDISpy it’s around 20%, with MIDISpy around 30%

  • @0tolerance4silence said:

    @Gravitas said:
    Try them on separate 'Tracks' with individual midi outs per 'Track'.

    More or less the same...
    Each track with an LFO modulating CC gen (multi) and sending out midi to AUM + midi monitor module on each track

    Without MIDISpy it’s around 20%, with MIDISpy around 30%

    It crashed here on the 9.7" iPad Pro which was actual unusual.
    I did use the 'CC generator' rather than the 'CC generator multi'.
    I'll do some more tests on the other idevice and see what happens.

  • edited September 2021

    @Gravitas said:

    @0tolerance4silence said:

    @Gravitas said:
    Try them on separate 'Tracks' with individual midi outs per 'Track'.

    More or less the same...
    Each track with an LFO modulating CC gen (multi) and sending out midi to AUM + midi monitor module on each track

    Without MIDISpy it’s around 20%, with MIDISpy around 30%

    It crashed here on the 9.7" iPad Pro which was actual unusual.
    I did use the 'CC generator' rather than the 'CC generator multi'.
    I'll do some more tests on the other idevice and see what happens.

    Strange, because CC gen midi resolution rounding was fixed couple of betas ago...

    Edit:
    Hmm... tried with CC gen, and it’s even better CPU wise (though I suspect a high performance core kicked in or something)

  • @0tolerance4silence said:

    @Gravitas said:

    @0tolerance4silence said:

    @Gravitas said:
    Try them on separate 'Tracks' with individual midi outs per 'Track'.

    More or less the same...
    Each track with an LFO modulating CC gen (multi) and sending out midi to AUM + midi monitor module on each track

    Without MIDISpy it’s around 20%, with MIDISpy around 30%

    It crashed here on the 9.7" iPad Pro which was actual unusual.
    I did use the 'CC generator' rather than the 'CC generator multi'.
    I'll do some more tests on the other idevice and see what happens.

    Strange, because CC gen midi resolution rounding was fixed couple of betas ago...

    Yup, that's what I thought also.
    I'll continue testing.

  • edited September 2021

    @0tolerance4silence

    9.7" iPad Pro iOS 13.4

    Air3 iOS 14.7.1

    No crash this time.

    Both projects had eight tracks with LFO’s into the ‘cc generator’ module
    being sent out via 8 separate Midi channels.

Sign In or Register to comment.