Is My Idea Possible?

I know… in the world of programming, anything is possible! But since lua is a scripting language and (potentially? don’t quote me on this though, i’m not here to get into a programming language war!) not as powerful as other such languages (Java, C++, C#, etc… ) i’m just a little unsure if what I want to achieve is possible.

Anyway… so I’ve been a beginner to intermediate programmer for the last 4 or so years of my life. I’ve always wanted to dive into learning lua for renoise purposes but I’ve always struggled to motivate myself for it, I suppose I’m one of those people who are unable to learn things for the sake of it, I’d rather be learning whilst building something! But the problem is I’ve never really had a good idea for a tool for renoise… until now of course!

Basically I want to re-create a favourite VST of mine, the MPC-style sampler Poise (… I want to recreate it because basically i don’t have the money to buy it but i’ve used the demo version and I absolutely love it. So I guess what I’m saying is… is this possible with the renoise api? my end-goal would be to recreate all of the functionality of poise which I’m not awfully confident of doing but if I know it’s possible it would certainly motivate me a lot more!

And if it is possible, any direction on what to learn specifically would be great.



Lua is fairly simple to learn, so if you have previous programming experience, you should pick it up pretty quickly.

Recreating something like Poise is possible by creating a GUI ‘wrapper’ interface in Lua to the native Renoise sample instruments.

Taking each Poise feature in turn:

  • 16 Drum Pads.

This is fairly easy, a simple grid of 4x4 buttons in your tool window, add midi and keyboard mappings to these buttons so users can use controllers.

  • 8 Samples per Drum Pad.

This is possible as you could dynamically create sample mappings that overlap (e.g. use C4-E5 as your 16 ‘pads’, sample mappings are one note in width, muliple samples per note gives you > 1 sample per ‘pad’. You could even add velocity maps, so some sounds only trigger when you have a higher velocity (for example).

  • Integrated sample browser with preview.

Use the native Renoise sample file window in the top pane.

  • Drag and Drop sample loading.

Unfortunately not. You cannot drag and drop onto tool windows. I propose a list box (8 entries) which updates with the names of the (up to 8) samples for the last played / selected pad. Simple add / remove sample buttons would change this list (you can make a sample loading file chooser appear).

  • Loads 8,16,24 and 32 bit WAV, AIF and SND files.

Renoise supports a variety of common sample formats.

  • Multiple Sample switching modes: Round-robin, random, layered and velocity.

Round-robin and random no, but layered and velocity mappings are possible.

  • Amplitude and pitch evelopes for samples.

Yes, but you are limited to a single envelope per parameter per instrument, which would affect all samples within it.

  • Inbuilt effects include distortion, lowpass filter, highpass filter and ring modulation.

XRNI format has a range of filters, distortion effects etc. Again, these have envelopes, but affect all samples.

  • Humanisation.

This is more of a sequencing function than part of the sample tool.

  • 2 - 16 stereo outputs.

Theoretically yes, if you created multiple tracks (perhaps within an instrument group track).

  • Edit multiple pads simultaneously.

Probably could be done.

I’ve written a variety of tools which can be found via my sig below. Feel free to download and investigate their code. Most of it is reasonably well written and commented, however, there are some bits which have been optimised (especially Cells!) and could be harder to follow.

Additionally, most people on here are friendly and will help you out with any coding issues you may come across.

Look forward to seeing a potential future tool.

Let’s be honest, it’s a lot cheaper to buy the VST than to learn to program well enough to be able to recreate it from scratch. :D

Thanks a lot for a very informative post! This has definitely given me the motivation to get started right away.

Just to clarify one thing; concerning the amplitude and pitch envelopes… my understanding of what you say is that I could load 16 samples on each drum pad individually, but could not control the amplitude/pitch for each sample individually? The main bit of this feature I particularly enjoy on poise is being able to alter the attack/release/sustain etc on each sample individually… I feel a little sad knowing I wouldn’t be able to recreate this :(

Despite this, i’m still pretty excited knowing that a lot of what I want to accomplish is very doable. So thank you!

True enough. Although I have a lot of free time on my hands! And i’m eager to not only get back to learning programming (I’ve found myself really on a programming absence lately… ) but to also involve myself in the renoise community more and contribute back to the DAW that i’ve very much fallen in love with :P

Suva is a nobody ( ), simply go for it

Parameters, yes, envelopes no.

Let me explain…

Each sample has a number of parameters as shown here:

In your situation, each sample can have a volume / panning / transpose / fine tune parameter, but these will be fixed values.

However, each instrument has envelopes (e.g. volume) like this:

But these are instrument wide and thus will apply to all the samples within the instrument.

Hope this clears things up.

Disregard Suva, aquire knowledge! :)

Much more understanding now, thank you sir!

PS: Couldn’t help but notice the ‘alpha testers’ group you’re in… is this group a voluntary group or is it a chosen one? I’d love to be a part of this group.

I recommend both- save for the VST and make your own plugin.

Alpha testers are chosen, usually based on the amount of knowledge they show with Renoise, these testers usually also intend to work on/with areas in a way most users don’t go.
And Alpha testers are usually also the people that spend most of their spare time on Renoise that they have to spend within the 24/7 period.

I have forgotten about the Hazing rituals:
1: You have to swim without a cage among the white sharks at Cape Hope, with a bag of dead fish and attempt to make the coast alive.
2: Swim across the Nile in Egypt in a crocodile infested area without being eaten.
3: Get bitten by a cobra and survive its venom injection.

Of course, you don’t need to do all three, just surviving one of them is enough, we don’t make things too hard in life.

I see. I don’t think I’m quite ready for the role of alpha tester just yet… I enjoy living too much.

I noticed how it was used in the video on the Poise website. With round-rubin, you basically get a sequence that you can control - each tap leading to the next sound, and the next … until it repeats over again.
I’ve tried it with e-drums, and it’s incredibly fun to play a drum-kit that constantly gives you new sounds :slight_smile:
I think it would be possible to get round rubin support, using scripting. At least, worth trying :yeah:

@mxb: Some really good points there

since it’s clearly the “hello world” of this project to make a button that produce a sound, I would like to contribute with something too (we talked a bit about some standard libraries?)
Well, the Duplex VoiceManager class could be adapted to make this easier. It basically keeps track of each note that has been triggered via MIDI or OSC (eliminates stuck notes when transposing, etc.).

Pfffft. Hold my beer, I’ll start with the cobra thing.

That’s the first thing that came to my mind too: It’s not something super straightforward, but probably could be hacked around with success.

Surely a Script could do Round Robin. Going via a Script do you really need all your Samples stored in the same Instrument? This will also give access to different Envelopes per sample. Sure somebody could knock together a proof of concept with a single note cycling through a bunch of notes/instruments…

But the API isn’t realtime so how accurate it will be, in regards both lag and jitter (variation in lag) is quite questionable.

EDIT: Doh! See that has basically been said already.

According to taktik, minimal response time is around 10ms, but you are right that a bogged-down computer would be even more sluggish.
However, since we are not talking about a sequencer, but a sample trigger I think there are two important points to consider:

  1. Just how precise are you as a finger-drummer?
    For most people, 10ms is “hardly noticable” when doing basic finger drumming
    (yeah, as much as you’d like you don’t reach Araabmuzik’s level without a lot of practice).

  2. Direct-to-pattern output
    Basically, I’m talking about a potential feature which would record the input directly to a pattern, instead of triggering notes.
    Benefits are huge: stuff like precisely quantized notes and note repeat would become possible :slight_smile:

Minimal being the operative word here. Although, as Tools run in the GUI thread, which refreshes at 50-60Hz in most cases, would an up to 20mS delay be more realistic?

Sure I’ve read that a piano has a delay of around 5-6 mS from pushing a key to hearing the hammer strike the string. That is also about the same as a guitarist standing a few feet from his amplifier. I know I can start to feel it when using a MIDI keyboard of around 8-10mS reported by the audio interface driver (and I can’t play!), but round-trip is double that stated is it not? Or is MIDI totally separate to audio delay? Even so 10-20mS may be usable if not 100% comfortable, until you get into a CPU intensive song and the GUI/Tool thread suffers serious hangups before the Audio thread.

Me personally? I can’t drum for shit!!! Wish I could but meh!.. ;)

Agreed, but lets not overload iamjoey just yet. First you have to get them addicted, help them out with free hints and tips etc. ;)

Presumably this is via local OSC loopback? This is how it works in Cells! in jam mode and it’s fairly responsible imho.

Wait… what? I just had to agree to letting my feet be washed? Maybe I just have purdy feet? :P


I suggest you start out with just getting a 4x4 grid of buttons which trigger notes when pressed.

If you program the tool to respond to Midi (and cast to the instruments using OSC), you don’t need the sluggish GUI for input.
The only thing is the round robin thing, fastest is if each sample simply represents an instrument, but you could do something with dynamic sample mapping in the note-on layer, before the midi note is casted to the instrument, but that will drag down the speed.

Ahh does it not? I guess that makes sense as although API LUA is in the GUI thread it would be bizzare if the native MIDI and OSC, both of which I believe utilise LUA, were as well. Good to hear and it sounds like it could be very much usably responsive then :D

Well, i may still dream about a JIT Lua thread may i? :P

Surely this depends how the tool works? If you wish to make sounds when the sequencer is not running, you would need to trigger notes via local loopback to the OSC server. This would be true regardless of how the lua function was triggers (midi or gui).

Here’s one ;) :P