Loopy Pro: Create music, your way.

What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.

Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.

Download on the App Store

Loopy Pro is your all-in-one musical toolkit. Try it for free today.

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

1…5657596162…64

Comments

  • 0tolerance4silence0tolerance4silence

    @Gravitas
    👍
    Time to leave the stage... I believe this is what some call ‘Drambo fanboys occupy the thread’ :)

  • GravitasGravitas

    @0tolerance4silence said:
    @Gravitas
    👍
    Time to leave the stage... I believe this is what some call ‘Drambo fanboys occupy the thread’ :)

    Lololol….
    I’ve gone already.
    Catch up. 😏

  • andrevjunqueiraandrevjunqueira

    @uncledave 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.

    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.

    It seem that MIDI Monitor here only receives the new value. It only updates de display with the new value.

    But in my usage, LFO is generating CC values, and if the frequency is high and a lot of CC s being generated and MIDI Monitor is displaying a lot os data, is when DSP usage increases - I am using dRambo to generated CC by LFOs like those Rozeta Suite apps.

    And yes, totaly agree with your point about DSP!

  • andrevjunqueiraandrevjunqueira

    @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 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)

    I just did a video showing the behaviour I am having here with dRambo.

    New AUM project with one AUv3 dRambo and 4 instances of Moog Model D - to put performance over 40% and activate the performance cores - similar load to my main AUM project.

    Alternating between 2 dRambo projects - one with 8 LFO CC generators with MIDI Monitor on each track and other without the MIDI monitor.

    In the video is possible to see the DSP load increase when I load the drambo project containing the MIDI Monitor. i’ts even possible to see the DSP going red over 100% and glitching AUM.

    Below are the AUM and dRambro projects in case someone would like to try to replicate the test. (moog Model D needed)

    And the video:

    https://youtu.be/EJ-7FAF5SnY

  • MadGavMadGav

    Can any of you tell me whether the Sampler module will read loop points from wav files? I’ve tried this but not certain the file had the loop point set correctly. Would certainly be handy to me… (in this case I got a decent result with manual adjustment in D)

  • 0tolerance4silence0tolerance4silence
    edited September 2021

    @andrevjunqueira 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 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)

    I just did a video showing the behaviour I am having here with dRambo.

    New AUM project with one AUv3 dRambo and 4 instances of Moog Model D - to put performance over 40% and activate the performance cores - similar load to my main AUM project.

    Alternating between 2 dRambo projects - one with 8 LFO CC generators with MIDI Monitor on each track and other without the MIDI monitor.

    In the video is possible to see the DSP load increase when I load the drambo project containing the MIDI Monitor. i’ts even possible to see the DSP going red over 100% and glitching AUM.

    Below are the AUM and dRambro projects in case someone would like to try to replicate the test. (moog Model D needed)

    And the video:

    https://youtu.be/EJ-7FAF5SnY

    The more visual activity going on your screen, the more taxing it will be on your CPU. I’m not sure what’s the goal here... if reducing CPU hit, there are several things you can do to achieve that:
    Like mentioned earlier, use CC gen (multi) instead. Better optimised in current D version.
    Scale module is unnecessary, ‘Amount’ knob on the LFO does exactly the same thing.
    If CC gen (multi) was used, you could get rid of the first Knob module as well as Add module.
    These are minimal changes that may help reducing CPU.
    Getting rid of Oscilloscopes and Midi monitors should definitely help to reduce CPU.
    Additionally your LFOs racked inside an instrument rack, sending out audio... even though it’s inaudible, it means there is a completely unnecessary audio summing happening inside D. Shouldn’t be too taxing, but if the goal is to optimise than worth changing.
    About 70-80% of your project does nothing in terms of functionality, which is sending LFO signals out to AUM.
    Happy to help to optimise if needed.

  • GravitasGravitas

    @0tolerance4silence said:

    @andrevjunqueira 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 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)

    I just did a video showing the behaviour I am having here with dRambo.

    New AUM project with one AUv3 dRambo and 4 instances of Moog Model D - to put performance over 40% and activate the performance cores - similar load to my main AUM project.

    Alternating between 2 dRambo projects - one with 8 LFO CC generators with MIDI Monitor on each track and other without the MIDI monitor.

    In the video is possible to see the DSP load increase when I load the drambo project containing the MIDI Monitor. i’ts even possible to see the DSP going red over 100% and glitching AUM.

    Below are the AUM and dRambro projects in case someone would like to try to replicate the test. (moog Model D needed)

    And the video:

    https://youtu.be/EJ-7FAF5SnY

    The more visual activity going on your screen, the more taxing it will be on your CPU. I’m not sure what’s the goal here... if reducing CPU hit, there are several things you can do to achieve that:
    Like mentioned earlier, use CC gen (multi) instead. Better optimised in current D version.
    Scale module is unnecessary, ‘Amount’ knob on the LFO does exactly the same thing.
    If CC gen (multi) was used, you could get rid of the first Knob module as well as Add module.
    These are minimal changes that may help reducing CPU.
    Getting rid of Oscilloscopes and Midi monitors should definitely help to reduce CPU.
    Additionally your LFOs racked inside an instrument rack, sending out audio... even though it’s inaudible, it means there is a completely unnecessary audio summing happening inside D. Shouldn’t be too taxing, but if the goal is to optimise than worth changing.
    About 70-80% of your project does nothing in terms of functionality, which is sending LFO signals out to AUM.
    Happy to help to optimise if needed.

    I will add for experimenting and learning both
    the oscilloscope and the midi monitor are necessary.
    When you've finished checking something and you know it's
    responding the way you need it to, remove the respective modules.

  • Paa89Paa89

    Hi everyone, could someone please request a “Tuner “model ?
    I tried signing up to the website but I keep getting image verification and fail no matter what I choose.

  • rs2000rs2000

    @Paa89 said:
    Hi everyone, could someone please request a “Tuner “model ?
    I tried signing up to the website but I keep getting image verification and fail no matter what I choose.

    It's easy enough to make one on your own:

    I've set the bandwidth of each EQ to 0.03, you might want to change bw and center frequencies if you want less or more precision.

    Let me get back to you regarding the issue with signing up.

  • 0tolerance4silence0tolerance4silence

    @Paa89 said:
    Hi everyone, could someone please request a “Tuner “model ?
    I tried signing up to the website but I keep getting image verification and fail no matter what I choose.

    It’s been requested, and there’s been some movement in that area recently, though it’s quite low priority at the moment.

  • Paa89Paa89

    @rs2000 said:

    @Paa89 said:
    Hi everyone, could someone please request a “Tuner “model ?
    I tried signing up to the website but I keep getting image verification and fail no matter what I choose.

    It's easy enough to make one on your own:

    I've set the bandwidth of each EQ to 0.03, you might want to change bw and center frequencies if you want less or more precision.

    Let me get back to you regarding the issue with signing up.

    This looks interesting let me try and replicate. Thanks for posting.✌🏾

  • Paa89Paa89

    @0tolerance4silence said:

    @Paa89 said:
    Hi everyone, could someone please request a “Tuner “model ?
    I tried signing up to the website but I keep getting image verification and fail no matter what I choose.

    It’s been requested, and there’s been some movement in that area recently, though it’s quite low priority at the moment.

    Oh i see. Thanks for the heads-up.

  • andrevjunqueiraandrevjunqueira

    @Gravitas said:

    @0tolerance4silence said:

    @andrevjunqueira 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 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)

    I just did a video showing the behaviour I am having here with dRambo.

    New AUM project with one AUv3 dRambo and 4 instances of Moog Model D - to put performance over 40% and activate the performance cores - similar load to my main AUM project.

    Alternating between 2 dRambo projects - one with 8 LFO CC generators with MIDI Monitor on each track and other without the MIDI monitor.

    In the video is possible to see the DSP load increase when I load the drambo project containing the MIDI Monitor. i’ts even possible to see the DSP going red over 100% and glitching AUM.

    Below are the AUM and dRambro projects in case someone would like to try to replicate the test. (moog Model D needed)

    And the video:

    https://youtu.be/EJ-7FAF5SnY

    The more visual activity going on your screen, the more taxing it will be on your CPU. I’m not sure what’s the goal here... if reducing CPU hit, there are several things you can do to achieve that:
    Like mentioned earlier, use CC gen (multi) instead. Better optimised in current D version.
    Scale module is unnecessary, ‘Amount’ knob on the LFO does exactly the same thing.
    If CC gen (multi) was used, you could get rid of the first Knob module as well as Add module.
    These are minimal changes that may help reducing CPU.
    Getting rid of Oscilloscopes and Midi monitors should definitely help to reduce CPU.
    Additionally your LFOs racked inside an instrument rack, sending out audio... even though it’s inaudible, it means there is a completely unnecessary audio summing happening inside D. Shouldn’t be too taxing, but if the goal is to optimise than worth changing.
    About 70-80% of your project does nothing in terms of functionality, which is sending LFO signals out to AUM.
    Happy to help to optimise if needed.

    I will add for experimenting and learning both
    the oscilloscope and the midi monitor are necessary.
    When you've finished checking something and you know it's
    responding the way you need it to, remove the respective modules.

    Yes @Gravitas

    I will do that. Minimize the use of both oscilloscope and midi monitor.

    I did others experiments with another midi monitor on AUM (mfxMonitor) and it also freezes with a lot of midi messagens…..

    Both drambo midi monitor and mfxMonitor at some point even freeze my iPad when used under high DSP load (over 40% in my tests)….. something to do with iPadOS itself……. :disappointed:

    Now the chase for a stable setup on 8th gen iPad goes on, now without midi monitoring. On another discussion here someone suggests disabling mic access to some apps, especially IAA. It’s working for me - improved stability overall.

    Thanks!

  • GravitasGravitas

    @andrevjunqueira said:

    @Gravitas said:

    @0tolerance4silence said:

    @andrevjunqueira 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 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)

    I just did a video showing the behaviour I am having here with dRambo.

    New AUM project with one AUv3 dRambo and 4 instances of Moog Model D - to put performance over 40% and activate the performance cores - similar load to my main AUM project.

    Alternating between 2 dRambo projects - one with 8 LFO CC generators with MIDI Monitor on each track and other without the MIDI monitor.

    In the video is possible to see the DSP load increase when I load the drambo project containing the MIDI Monitor. i’ts even possible to see the DSP going red over 100% and glitching AUM.

    Below are the AUM and dRambro projects in case someone would like to try to replicate the test. (moog Model D needed)

    And the video:

    https://youtu.be/EJ-7FAF5SnY

    The more visual activity going on your screen, the more taxing it will be on your CPU. I’m not sure what’s the goal here... if reducing CPU hit, there are several things you can do to achieve that:
    Like mentioned earlier, use CC gen (multi) instead. Better optimised in current D version.
    Scale module is unnecessary, ‘Amount’ knob on the LFO does exactly the same thing.
    If CC gen (multi) was used, you could get rid of the first Knob module as well as Add module.
    These are minimal changes that may help reducing CPU.
    Getting rid of Oscilloscopes and Midi monitors should definitely help to reduce CPU.
    Additionally your LFOs racked inside an instrument rack, sending out audio... even though it’s inaudible, it means there is a completely unnecessary audio summing happening inside D. Shouldn’t be too taxing, but if the goal is to optimise than worth changing.
    About 70-80% of your project does nothing in terms of functionality, which is sending LFO signals out to AUM.
    Happy to help to optimise if needed.

    I will add for experimenting and learning both
    the oscilloscope and the midi monitor are necessary.
    When you've finished checking something and you know it's
    responding the way you need it to, remove the respective modules.


    Yes @Gravitas

    I will do that. Minimize the use of both oscilloscope and midi monitor.

    I did others experiments with another midi monitor on AUM (mfxMonitor) and it also freezes with a lot of midi messagens…..

    Both drambo midi monitor and mfxMonitor at some point even freeze my iPad when used under high DSP load (over 40% in my tests)….. something to do with iPadOS itself……. :disappointed:

    Now the chase for a stable setup on 8th gen iPad goes on, now without midi monitoring. On another discussion here someone suggests disabling mic access to some apps, especially IAA. It’s working for me - improved stability overall.

    Thanks!

    Giku has mentioned that there is a bug connected
    with this on the Beepstreet Forum which they are fixing.

    I did try disabling the mic access for dRambo to see if it would
    improve stability but I sat there for ten minutes wondering
    ‘Why am I not getting any sound?’.
    Switched back on mic access for dRambo and all was good again.
    I think the mic access thing works for IAA more than for auv3’s
    or stand-alone.

    You’re welcome.

  • Michael_R_GrantMichael_R_Grant

    I just received a Faderfox UC4 in the post and MIDI mapped it to a test Drambo project. Wow, what a game-changer! I mapped the 8 faders to each track volume, the knobs to various parameters, the cross-fader to scenes, buttons to things like Record and Play... even out of the box, it was bloody excellent. Once I fully figure out how I want to use it, and also connect up my little Roli Lumi, the amount of direct control I'll have over the app will be pretty amazing!

  • Michael_R_GrantMichael_R_Grant
    edited September 2021

    Does anyone know how I can map the record button in Atom 2 to a trigger button in Drambo so that I have an on/off switch accessible directly from the module? I can map ‘record’ in Atom 2 to make a knob appear in the Drambo module interface, but can’t work out how to translate that to an on/off trigger. I tried creating a Trigger button to modulate the knob, but unless I can’t figure out the right settings for knob strength for the Trigger and knob position for the ‘Record’ mapping, it isn’t working for me. I feel like this should be possible, though. Ultimately I’m trying to assign a button on my Faderfox UC4 to activate Record in Atom 2, but feel like I have to do the following:

    • Hit ‘Map’ in Drambo when the Atom 2 is full screen in order to make a mapping knob appear.
    • Somehow get a trigger button to work with that knob as an on/off switch.
    • MIDI map my Faderfox UC4 button to that trigger.

    This is because it doesn’t seem like I can MIDI map directly from the Atom 2 AU to my Faderfox within Drambo. Any ideas?

  • 0tolerance4silence0tolerance4silence
    edited September 2021

    @Michael_R_Grant said:
    Does anyone know how I can map the record button in Atom 2 to a trigger button in Drambo so that I have an on/off switch accessible directly from the module? I can map ‘record’ in Atom 2 to make a knob appear in the Drambo module interface, but can’t work out how to translate that to an on/off trigger. I tried creating a Trigger button to modulate the knob, but unless I can’t figure out the right settings for knob strength for the Trigger and knob position for the ‘Record’ mapping, it isn’t working for me. I feel like this should be possible, though. Ultimately I’m trying to assign a button on my Faderfox UC4 to activate Record in Atom 2, but feel like I have to do the following:

    • Hit ‘Map’ in Drambo when the Atom 2 is full screen in order to make a mapping knob appear.
    • Somehow get a trigger button to work with that knob as an on/off switch.
    • MIDI map my Faderfox UC4 button to that trigger.

    This is because it doesn’t seem like I can MIDI map directly from the Atom 2 AU to my Faderfox within Drambo. Any ideas?

    You can have a switch in Drambo UI to initiate rec without entering A2...
    For that use Switch module rather than Trigger button (which is just a short click, trig instead of gate).

    Or to map to a controller, enter midi map mode, highlight record knob on the module, use button on the controller to assign and additionally you may need to adjust control type...

    Toggle or momentary modes included to accommodate various controllers, also sometimes continuous absolute works fine, but other modes get selected automatically. (Too many ways these things are being implemented).

    Edit:
    To map rec knob from ‘Atom2 module’ you won’t need Switch button. You first map it from Atom2 UI, so it’s accessible from the native module UI, then you map that to your controller using Drambo midi map/learn. (and like mentioned above, you may need to adjust auto-selected settings, to accommodate your controller)

  • Michael_R_GrantMichael_R_Grant

    That's really helpful, @0tolerance4silence. I'll give it a go!

  • Model10000Model10000
    edited September 2021

    Seems Drambo beta has a piano roll. Was a Gikubeep leak so don’t shoot the messenger 😏

  • SamuSamu

    @Model10000 said:
    Seems Drambo beta has a piano roll. Was a Gikubeep so don’t shoot the messenger 😏

    The P-Roll has already been mentioned in the Drambo forum but no additional details until da master approves ;)

  • Model10000Model10000

    Ha, yeah been trying to piece together all he’s cooking up there 🤓

  • FingolfinzzFingolfinzz

    I can’t wait for this update, it’s going to be so amazing just from the snippets of what I have heard

  • NoiseFlooredNoiseFloored

    @Fingolfinzz said:
    I can’t wait for this update, it’s going to be so amazing just from the snippets of what I have heard

    It's gonna be real and spectacular

  • FingolfinzzFingolfinzz

    @NoiseFloored said:

    @Fingolfinzz said:
    I can’t wait for this update, it’s going to be so amazing just from the snippets of what I have heard

    It's gonna be real and spectacular

    :)

  • LorichsLorichs

    Hi all drambo black belts out there.
    Is there a way to set an effect post-fader on the main track the way you you can do it in AUM? Sometimes I don’t that i don’t to use an fx-bus?

  • skratskrat

    @Lorichs said:
    Hi all drambo black belts out there.
    Is there a way to set an effect post-fader on the main track the way you you can do it in AUM? Sometimes I don’t that i don’t to use an fx-bus?

    You can create own track with your own routings. Just add an extra "Post-fader" track after e.g. Master and put the processing in it. Then even after turning down Master, the Post-fader track still outputs sound, e.g. the tail of reverb or delay.

  • LorichsLorichs

    Thanks @skrat
    Yeah you got it. I just never get tired of these loooong juicy reverb/delay tails 😊.

  • LorichsLorichs
    edited November 2021

    Deleted …. I figured it out 😉

  • sigma79sigma79

    When I route drambo to aum using audio 4c. Drambo track and master out are on full but its about 20db less than aum standard. Think it might be similar in db if reciever aum fader is full.

    Is there an aum or drambo setting. Or if I think its similar db with aum fader full. Then just have fader full for the drambo being recieved?

  • sigma79sigma79

    Its not. Its just the synth. I think.

Sign In or Register to comment.

© Vanilla Keystone Theme 2024