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 StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
Opening apps to basic programming (variables, if/else, arrays…). What do you think?.
This is a thought I’ve encountered many times while knee-deep in apps like Drambo or Loopy Pro. These apps are super deep and let you build very complex setups but I often miss the option to just set a Boolean or array or check for a value instead of having to go through a ton of modules and connections that translate into some odd cv value (Drambo) or have to switch profiles or add a ton of events to do some operation (Loopy).
Under the hood they already translate anything you do on the UI to variables, arrays, objects and programming logic. So I find that exposing options to set a variable (nextClip=3) or act on one (if lastClip=true nextClip=0) would indeed make things a lot simpler and open up a ton of possibilities.
I’m not talking about complex stuff like that of Streambyter or Mozaic, just some (optional) value reading and setting.
I know this would break the “magic” for many. The CV stuff in Drambo is vintage and cool, but is it easier than just setting a variable?. In Drambo you set up a module with values, connected to a button that triggers the change, to something that translates that (0.66) value to something that makes sense…. All that to just set an array. Why not just set the array?.
Or loopy… With some minimal array stuff you’d be able to trigger loops randomly, act differently if the loop is empty or not… Or just use one master template and set up sections via arrays, instead of having to add a dozen clip actions that will need to be re-programmed if you decide you’ll have 3 song sections instead of 4.
My point is, I’m many cases by avoiding “complicated geek stuff” things actually end up being a lot more complicated and require more time and knowledge. As for the obvious worry that this might break stuff… Not really, we’re talking about simple stuff here that’s really easy to check in code, it’s basically doing with one line of text what you’d do with the provided modules.
Interested to read your opinions on this.
Comments
First of all, the Graphic Shaper can provide arrays in a fairly straightforward way and the Oscilloscope gives you a numerical value display if you don't want to adjust specific points by ear.
A more flexible formula module, maybe also including arrays, might come in the future if more users want it.
As a Linux user who uses it as the main OS both for work and personal stuff for decades, I know exactly what you are talking about. I can achieve many tasks much easier and quicker via the command line than through the GUI.
For the iPad the core problem I see with this is the actual text input. You either need an external keyboard, or you have to sacrifice half of your screen to the virtual keyboard - what often drives me nuts.
Personally I would love to see an embedded macro language in many music apps. Audulus and TouchOSC for example have built in Lua interpreters. It would be great to have a macro module similar to the Audulus DSP module in Drambo.
At the moment I avoid the problem of having too many modules in Drambo projects by using Racks. Racks are a bit like the “Drambonian” version of classes, subroutines or declared functions.
There's a basic technical problem with this. These apps all use compiled code. So there are no named variables or arrays in the executable code, just very inscrutable references to addresses and registers, implemented by machine instructions. And these things are built of nested objects, so the top level code in a Drambo module (say) does not know how its data is stored, making it difficult to expose this data to an interpreted user interface.
Adding an interpreter module, as suggested by @catherder, would allow implementation of algorithms, but it would be limited to the normal module inputs and outputs. It could not access internal data of other modules.
This probably depends on the programming structure of the main application. Talking as a dev here: I am assuming that in Drambo each module is represented internally as a class, and loading a module instantiates the class. Any parameter that is made public in the class should possibly be accessible from the outside. Many applications like LibreOffice for example have an internal object structure that can be accessed in this way from the macro system. And this even works cross-language: CSound for example is written in C and can be accessed from Python.
@catherder Sure, all easy when you're not dealing with a realtime application where processing latency is not an issue 😉
Speaking as a developer myself: If the module class is written in C++, its public members can be accessed from outside, given the object reference (pointer), the header files defining the class and its member classes, and a C++ compiler. Making that data accessible to a real-time interpreter would require providing a wrapper compatible with the interpreter. I believe this is how the CSound.py Python package is implemented. A separate wrapper would be needed for each module class, and for any exposed member classes, such as arrays. So, it is feasible, but is a much bigger implementation task than implied in the OP.
I don't believe that the CV stuff in Drambo is included because it is "vintage and cool". It's done that way because it integrates naturally with the rest of the modular architecture: racks, play/pause, pLocks, polyphony, etc. The Drambo supervisor knows how to handle each module in every condition. Throwing in random operations could break all that.
That said, a programmable CV operator module could be interesting, with say 10 inputs and 10 outputs. Could be a bit of work to implement, though. Maybe bootleg a copy of original Microsoft Basic...
Very interesting comments!.
Regarding classes, public members, etc… For the purpose of this post, I’d be enough to have some “global” variables and arrays, it’s just simple stuff. When I mean global, it could be a singleton config class or whatever, that’s available everywhere. Set some values, read some values, nothing intricate. I don’t intend to get too technical here but I don’t see how it’d be a problem. If you have a slider in Drambo or a clip event in Loopy, you’re also setting values and variables…
I didn’t mean the “vintage and cool” to sound offensive, I meant that it sticks to “analog” synth operation stuff, which is great but not easy to grasp. Regarding modules and conditions… I don’t get the impediment. In Drambo you can already set whatever number, multiply by whatever and send the output via modules. You can also send a signal one way or another based on conditions… I just find it frustrating and cumbersome to have to hook a ton of modules to set and read some values…
We’re focusing on Drambo here but I insist id be very useful for any modular app like Loopy.
@tahiche : it would be great to scripting in loopy and had Bern discussed. But implementing even simple scripting is a more complex task than you probably imagine — it isn’t a case of “implementing something simple is simple”. Loopy Pro may well get it at some point (it may even be likely). It is a very non-trivial task. It is likely not happening soon as Michael’s plate is pretty full of even higher-priority items.
While a little time-consuming to set up initially, Loopy’s follow actions plus Streambyter or Mozaic make it possible to implement a simple state machine that tracks the state of the clips in an array and let’s you do pretty sophisticated operations.
Not sure what you mean by a "singleton config class or whatever, that’s available everywhere". Are you thinking of one collection of variables and arrays for all of Drambo (or Loopy Pro)? How would those values be connected to the modules you want to affect? You could use Drambo's normal "wiring" method to connect those "variables" to any of the normal module inputs or modulators. That would be essentially the 10 in/10 out script module I suggested. But it wouldn't have access to internal module data. It would just be a different way of implementing the logic and math modules you dislike.
From your original post ("nextClip=3"), I understood that you wanted to access internal data in specific modules. That would require that each Drambo module provide an interface offering access to its member data by name. That's the problem with providing script access. It's not just about setting values and variables, but accessing them by name. As I said earlier, there are no names in the compiled code when it's running. Providing such a named interface is feasible, but would be quite a lot of work for each module, for relatively small benefit, since this is likely to be a niche use.
You do not actually do those actions in Drambo, you tell Drambo to do them. It runs in a loop as it chooses, does those calculations when and how it chooses. It does the calculations multiple times if polyphony is involved. Supporting script access to module internals could upset the way that works.
If you're satisfied with what the math and logic modules can do, but find the interface frustrating, then what you want is just the programmable CV module I already suggested. That would still be a big job, but it wouldn't require access to internal data of other modules, so it would fit in the Drambo architecture.
I was thinking something like this might be feasible with a very limited scope. Perhaps an app such as Drambo or Loopy could provide a set of user variables and a way to edit them. Then, in things like modules and settings, wherever values can currently be typed in (both Loopy and Drambo have this), instead one could refer to a variable. For instance instead of a number, one could enter something like
{%1}to get the User 1 variable value.Of course then people would want equations, and string variables, and arrays, and ways to set variables from AUv3 parameters, etc. etc. etc. The complexity would skyrocket going beyond just very, very basic substitutions.
tbh, it's an intriguing idea that I think sounds more useful than it probably would be in practicality, and could be a big can of worms as far as complexity.
Great out of the box thinking though! So much so that I hate to be so pessimistic about it. Decades of ingrained cost vs. benefit analysis bias dies hard.
That's an interesting approach. Do you see
{%1}as making that connection permanently, so the variable in that entry slot is permanently connected to the user variable? It's a nice way of getting at values not accessible as inputs or modulators.Yes, that's what I was suggesting. So, once referenced, the value would be substituted as the variable's value changed. If it was an AUv3 parameter or otherwise settable by a midi CC, that could open up some possibilities. For instance, it could be useful for amorphous apps such as Loopy Pro and Drambo, where trying to expose everything as a parameter is pretty much impossible.
I don't think it's as useful a thing as it seems in all practicality though.
There’s a lot of ways to set and access user variables. Think of the “global settings” in an app, they can be set and read from any module, sub-component or app part. I was thinking of a config service class that you inject into constructors, that’s common in web development, but I don’t see how that’d be a problem. Again, think of the global config of an app.
In a very simplistic manner when a user sets a named variable like “nextClip=3” via the UI, you’d call something like \MyApp->service(‘user-config’)->setVar(‘nextClip’, 3); then if the user wants to read that variable you can output all user-defined vars in a select or list (foreach \MyApp->service(‘user-config’)->getAll(); ). Or I also like @wim ’s approach of the {$1}, where the name of the variable is just for the user to identify, underneath what matters is the index.
It’s not that I dislike the math modules, and just to be clear I think Drambo is absolutely stunning and a lot of fun. It’s an AND not an OR.
I don’t believe adding simple functionality for setting and reading values, adding some very simple conditional logic would be too hard. But I do know this would be a wormhole for developers. We’d want more and more exposed values and to be able to set and affect everything. On the other hand it would open for a lot of flexibility for certain features that without these “user define” capability require some feature requests, a lot of work and can make apps bloated with a million options on the UI.
I like this idea! It's really a non-trivial amount of work to execute. It's potentially true that adding some setting and reading of values could be straightforward, as it could be essentially a different UI for existing behaviors. Anything beyond simple values, like conditional logic, is a much, much larger task. Even for the "simple" stuff, there's tons of room for user error. Maybe you have a variable
nextClip, but you've accidentally typednextClio. A compiler would catch this, but who catches it at runtime in the app? Mostly likely, the developer ends up having to add pretty robust error handling on top of all the work to make the system itself.Conceptually, I like the idea of the scene-global config as you're describing. It'd be nice to have a sort of outer layer to constrain larger, more open apps. I think there's a clash between a modular system, which is a good analog to functional programming, and globally shared data...so it'd really be interesting to think through how such a system would work without mucking up the modular feel!
VCV Rack has the Formula One module. You can write your own formulas and scripts and even send cv to the variables in your formula. Dunno if it's in Mirack or not.
https://github.com/docb/dbRackFormulaOne
MiRack is compatible with VCV Rack so maybe it could be ported over to MiRack
though in principle it would still function similarly to Streambyter and Mozaic.
Idea: iinstead of getting multiple developers to create or add new code, create a single MIDI AUv3 that can run scripts, and send its output to the exposed variables in existing apps.