Lua arpeggiator plugin anyone?

I have to agree. Hanging notes are the worst. Notes being cut short are equally bad for an arpeggiator, though. :slight_smile: But, as I said, I’ll just deal with that as best as I can in the plugin.

Robin, I’ve just released version 0.3 of the scripts at https://github.com/agraef/ardour-lua. Raptor now has some proper instructions in the README, and the arpeggiator plugins all have version information in their descriptions now, so that it becomes easier to know what version a user is running in case of bug reports.

I think that I am finished with these for now (bugfixes notwithstanding).

@aggraef
I’m again hugely grateful for the effort you’ve put in here, even if for my compositional style / usage patterns I’m unlikely to use the plugins:

  • The examples you have provided have opened my ears (at least a bit) to this kind of generative / algorithmic composition, which is a gift.
  • That you have put in the effort to grok the Ardor Lua API to this extent warms the cockles of my heart, because it gives me confidence that I might be able to use that API myself for some vague / notional future need.
  • That @x42 et. aliae have engaged so well with your effort is unsurprising, but still gratifying, as a justification for the F/LOSS community-based development model I love so much. I defy anybody to demonstrate a similar openness / flexibility in any similarly complex, proprietary software ecosystem.
1 Like

@tseaver, thanks for the kind words. And a big shoutout goes to Robin, without his involvement this effort probably wouldn’t have gone anywhere. The Lua API has advanced a lot since I last looked at it, and the ability to write MIDI plugins in Lua is a great boon IMHO.

BTW, Robin, one thing I’d really like to see added some time is an API for control surfaces. I don’t know whether that’s feasible, and I think that I’ve read somewhere that Paul prefers to have these things written in C++. But I have ready-to use Lua code lying around for interfacing the AKAI APC mini (both mk1 and mk2) to Ardour’s new clip launcher. This currently runs in Pd and utilizes Ardour’s OSC interface, but presumably it would be easy to port this over if the API was available in the Lua interface.

(The APC mini is a great budget option for a clip launcher, and the new version is a lot better, featuring true RGB colors for the pads and built-in drum and isomorphic keyboard modes. IMHO this is the best clip launcher that you can get right now at the $100 price point.)

If you’re interested, I can start a new thread about this, just let me know.

If not, well then I’ll wait for Paul’s Novation Launchpad driver and use that as a blueprint for an APC mini driver in C++, but frankly it would be much more fun for me to write this in Lua. :slight_smile:

1 Like

We’re very unlikely to do this. As you note, we have the option to provide support for any surface via C++, and that’s almost certainly the way it is going to stay for the foreseeable future.

Although we did distill down several of the common elements of what a control surface needs to do into libs/ctrl-interface/midi_surface it remains the case the the basic physical design of these things seems to continue to dictate a relatively unique approach per device.

That said, obviously both Bitwig and Reaper allow control surface support via their own scripting languages, so to some extent I’m full of crap.

1 Like

Ok, I understand. I naively assumed that the API was already there and just needed to be wrapped. But looking at DrivenByMoss, I can see that the task of designing such an API is an enormous project in itself, and I have to agree that development work is better spent elsewhere.

This is getting off-topic now, but there’s another little snag concerning MIDI controllers I keep running into. As far as I can tell, it’s only possible to use a single Generic MIDI control surface right now. Would it be difficult to adapt Ardour to have multiple controllers with different binding maps active at the same time? That is, instead of one “Generic MIDI” interface under “Control Surfaces”, have, say, three of them, or as many as one needs? I can work around that limitation by creating a single custom binding map for all the controllers I want to use, but that’s a little inconvenient.

IF we can, can we go ahead and make a new topic for the multiple midi controllers question? Thanks!

Seablade

Done, see Multiple "Generic MIDI" control surfaces

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.