Drum playing plugin

[curlymorphic]

It has been mentioned in issue #1087 about adding a sample based drum machine, and issue #1396 about adding a drum synth.

Tres has also suggested on the mailing list.

I hate to describe other DAWs, but the drum sample in Ableton is very simple and effective and IIRC, it -uses it's default sampler instrument for each individual sample but IIRC, it also can allow other instrument types.

This is not so much an instrument, more of a multi instrument host. The idea is that each drum sound is played by it's own instrument. our new drum instrument, simply routes the note data to the assigned instrument. ie the kick drum could use Kicker, the hats from Audio File Player, the toms form triple- oscillator. The choice of plugins would be down to the user. This does work very well in practice.

How ever i am unsure of the implications of this, And would like to know any thoughts on the idea. or even if it is possible?

[diizy]

On 12/18/2014 12:49 PM, Dave wrote:

It has been mentioned in issue #1087 https://github.com/LMMS/lmms/issues/1087 about adding a sample based drum machine, and issue #1396 https://github.com/LMMS/lmms/issues/1396 about adding a drum synth.

Sample based drum machine would probably be best. Kind of redundant since we can already use multiple AFPs in the bb-editor, and the bb-editor works best with each drum on their own track (seeing as there's no easy way to input pitched notes directly in the bb-editor) but some people want it so why not.

If you want to make a drum synth, then it would be best to look at the particular advantages you can get from a synth vs. using samples, and concentrating on leveraging those advantages. Something like using substractive synthesis (noise -> narrow band oscillating filters), maybe noisy envelopes, and other methods that add randomness and "humanization" to the sound, as this is something that isn't as easily achieved with samples.

Tres has also suggested on the mailing list.

I hate to describe other DAWs, but the drum sample in Ableton is
very simple and effective and IIRC, it -uses it's default sampler
instrument for each individual sample but IIRC, it also can allow
other instrument types.

This is not so much an instrument, more of a multi instrument host. The idea is that each drum sound is played by it's own instrument. our new drum instrument, simply routes the note data to the assigned instrument. ie the kick drum could use Kicker, the hats from Audio File Player, the toms form triple- oscillator. The choice of plugins would be down to the user. This does work very well in practice.

How ever i am unsure of the implications of this, And would like to know any thoughts on the idea. or even if it is possible?

Probably this is something that can't be implemented with just a plugin, but would require some structural changes in the core... not sure how smart it would be to start implementing something like this at a time like this. Maybe this could be revisited when we're in a more stable situation.

[tresf]

Kind of redundant since we can already use multiple AFPs in the bb-editor, and the bb-editor works best with each drum on their own track

The true value of a drum kit IMO comes from.

1. The ability to swap out one drumkit for another
2. Ability to use a single midi device or drum pad set to compose.

Although the solution seems redundant from a features perspective, from a usability perspective, it is far from redundant with any feature we have today. :+1:

[curlymorphic]

Tbh im not sure what lmms would gain by another drum synth, It already has kicker, and plenty of synths that can be used to make percussion sounds.

I do like the bb editor, step programming can be nice.

A drum sampler can do more than a simple AFP, layer samples, velocity sensitive layers, exclusive channels (for open and closed hats ), individual AD per layer, be played from a single midi instrument ( drum pads ), switch banks of samples, can also be used with random lfo's applied with tiny amounts to pitch, gain etc, to create that more realistic sound.

This is not so much an instrument, more of a multi instrument host. The idea is that each drum sound is played by it's own instrument. our new drum instrument, simply routes the note data to the assigned instrument. ie the kick drum could use Kicker, the hats from Audio File Player, the toms form triple- oscillator. The choice of plugins would be down to the user. This does work very well in practice.

Probably this is something that can't be implemented with just a plugin, but would require some structural changes in the core... not sure how smart it would be to start implementing something like this at a time like this. Maybe this could be revisited when we're in a more stable situation.

Although I feel as a user this would be the most powerful option, with each sound having it's own instrument, effects chain, and possible output to the fx mixer, I did feel that it would be more than just an instrument. I also dont understand the core well enough. So we had better put this idea on the shelf for another time.

This leaves the idea of a drum synth, or sampler,

@diizy @tresf @Lukas-W

Do you feel one of these would improve lmms at this current time, or would my time be better spent else where.

[diizy]

On 12/18/2014 04:17 PM, Dave wrote:

This leaves the idea of a drum synth, or sampler,

@diizy https://github.com/diizy @tresf https://github.com/tresf @Lukas-W https://github.com/Lukas-W

Do you feel one of these would improve lmms at this current time, or would my time be better spent else where.

IMO, if you want to make an instrument plugin, it doesn't have to be a drum synth/sampler. There are other areas where LMMS is lacking native synths. I have a couple of ideas:

• A linear arithmetic synth (only let's not call it that, to avoid lawsuits from Roland...) This is an interesting concept which basically combines sample playback with regular synthesis (bandlimited osc+filter), where the samples are used to provide an attack transient for the synth sound. We could develop the idea further by allowing modulations between the sample and the oscillator...
• A subtractive synth: we kind of already have this with Zyn, but the biggest flaw in Zyn is that only like two knobs can be automated, giving very little variation in the sound... maybe that will change in the future, but at the moment, Zyn is only half an instrument in my book. Anyway... subtractive synth: one noise generator, routed to n narrow bandpass filters placed at harmonic intervals... what would make it interesting vs. Zyn would be automatable bandwidth/magnitude controls for each harmonic, automatable envelopes for vol/pitch/bandwidth, etc... lots of possibilities.
• A sample scanner: basically, lets the user load a sample, then plays the sample in a very short loop, where the length of the loop is determined by the pitch of the note: eg. you play an A4, so the loop length would be samplerate/440 frames. Not sure how to handle fractions, possibly with some kind of interpolation. The idea is, that the position of the loop (or, the "scanning" position) can be modulated/automated, yielding a variable timbre oscillator. Another way to think of it would be as a wavetable synth, where the wavetable is picked out from a sample file...
• We also lack a granular synth... not going to explain this one, too complicated. Wikipedia can help better here...

So anyway, there's lots of possibilities for new instrument plugins... just do whatever you think sounds interesting. The important thing is that it brings something new and different to LMMS.

[softrabbit]

A drum sampler can do more than a simple AFP, layer samples, velocity sensitive layers,

Sounds like a job for a multi-sample sampler, maybe as a successor to the AFP?

exclusive channels (for open and closed hats ),

Could that be added to the BB-track features? (And a mono mode, where a drum hit would cut off the previous note playing on the same instrument would be cool too, but that should be useful for all instruments...)

And we do have the guts of a pretty capable drum synth with some 700 presets... it just needs a GUI and probably a good refactoring.

[diizy]

On 12/18/2014 04:39 PM, Raine M. Ekman wrote:

And we do have the guts of a pretty capable drum synth with some 700 presets... it just needs a GUI and probably a good refactoring.

What synth is that?

[softrabbit]

What synth is that?

The one loading .ds files into AFP.

[diizy]

On 12/18/2014 04:43 PM, Raine M. Ekman wrote:

What synth is that?

The one loading .ds files into AFP.

Oh. But we can already load .ds files into AFP directly, can't we? Also, .ds is kind of crappy as AFAIK .ds files can only be generated with a proprietary windows app...

[tresf]

Do you feel one of these would improve lmms at this current time, or would my time be better spent else where.

@curlymorphic this goes a bit into our future map both short-term (stable-1.2) and long-term (stable-2.0).

The good part about proposing this question is it opens up a casual conversation about the future of the software... something I think is a great discussion point since we all have a common goal to see the software mature.

The tricky part about proposing this question is that -- up until now -- our priorities tend to be silo-ed. Silo'd in a way that we tend to drive the future of the software as single activists toward individual ideas, rather than ones driven by consensus.

That said... I think if were we to focus efforts they'd be in the following areas:

• Undo. I consider lack of undo to be the number one feature gap with the software.
• Performance on Windows. Probably Aero caused, there are some usability setbacks that prevent the most basic of tasks from being performed without very bad chopping and latency on modern Windows versions.
• UI flowing widget layouts. As we add more items to our toolbars, the minimum width of items like piano roll prevent the most basic of split pane composition from a realestate perspective (forget the fact that piano roll is singleton -- just having it side by side with anything, really)
• VST compat. We have some relatively basic outstanding VST bugs which make some of the best plugins unusable with our software, such as improperly storing/reloading the VST data.
• MP3 support. This stirs controversy, but Audacity has a way of including the LAME libraries after install. We should consider this too.
• Apple support. We're about 5 bugs away from having a very good DAW on Apple.
• MIDI export. Self explanatory.

These are items off the top of my head I would regard as high priority from my humble perspective. :)

Sorry to toss this thread off-topic a bit and feel free to copy/paste these in as futuremap suggestions elsewhere. :+1: ... that said ... as we talk about where we spend our time, I think its good to identify areas that may yield more value with (speculatively) less effort.

[musikBear]

So anyway, there's lots of possibilities for new instrument plugins...

Loves those ideas, diiz! :ice_cream: I have speculated around some kind of 'wildcard' adressable dials for zyn. Perhaps the zyn midi-mapping of its internal controllers, could be user-mapped to an lmms 'wildcard' dial, that then could be automated

[curlymorphic]

• A sample scanner: basically, lets the user load a sample, then plays the sample in a very short loop

Now this sounds like an excellent variation on something i used to do with samplers. I am thinking about writing a basic version, to see if the idea is worth pursuing.

VST compat. We have some relatively basic outstanding VST bugs which make some of the best plugins unusable with our software, such as improperly storing/reloading the VST data.

What would this involve OS wise, just wine, or full windows(was trying to stay away from this)?

[diizy]

On 12/18/2014 06:50 PM, Dave wrote:

VST compat. We have some relatively basic outstanding VST bugs
which make some of the best plugins unusable with our software,
such as improperly storing/reloading the VST data.

What would this involve OS wise, just wine, or full windows(was trying to stay away from this)?

Linux + wine is fine. We can use windows VST plugins via wine anyway, so it's not just a windows problem.

However I'm a bit sceptical as to how much good can be realistically done here. VST is a closed, proprietary format, supporting it involves a lot of guesswork... I'm not really sure if VST support can get any better without access to Steinberg's source code.

[tresf]

VST compat. We have some relatively basic outstanding VST bugs which make some of the best plugins unusable with our software, such as improperly storing/reloading the VST data.

What would this involve OS wise, just wine, or full windows(was trying to stay away from this)?

Wine would most certainly be able to reproduce, granted the plugin is compatible with Wine.

Here are the findings (I've amended the appropriate info to the original bug report) :

https://github.com/LMMS/lmms/issues/1049

[tresf]

I'm not really sure if VST support can get any better without access to Steinberg's source code.

I agree that this is opening Pandora's box a bit if were to try to tackle all VST bugs and promise compatibility with all VST plugins... but if you take a look at the bug report above, you'll notice that one major bug is just a problem with the way we store and reload data, which should be reasonable enough to investigate.

[curlymorphic]

I will look into these vst issues. see if i can make any headway.

[tresf]

I will look into these vst issues. see if i can make any headway.

Great, we can discuss in that thread. I've modified the title and original bug report with my findings so that you don't have to scroll through the comments.

[tresf]

A drum sampler can do more than a simple AFP, layer samples, velocity sensitive layers,

Sounds like a job for a multi-sample sampler, maybe as a successor to the AFP?

Perhaps, or just an instrument container instrument. We'll want to tweak every AFP individually anyway, what's keeping us from making a container which gives us assignable notes?

-Tres

[Sti2nd]

not sure how smart it would be to start implementing something like this at a time like this

seriously, do you expect development to stop, or what?

I appreciate all the hard work, but as Raine said, don't let this turn into a one man show.

[diizy]

On 12/18/2014 09:56 PM, Stian Jørgensrud wrote:

seriously, do you expect development to stop, or what?

...it will if all the developers are busy answering silly questions... ;)

[softrabbit]

But we can already load .ds files into AFP directly, can't we? Also, .ds is kind of crappy as AFAIK .ds files can only be generated with a proprietary windows app...

It's open source, and LMMS uses the original rendering code: http://sourceforge.net/projects/drumsynth/ ...but whatever. I just thought a drumsynth with a pile of presets to start from would make more sense than one without.

[diizy]

On 12/18/2014 10:04 PM, Raine M. Ekman wrote:

But we can already load .ds files into AFP directly, can't we?
Also, .ds is kind of crappy as AFAIK .ds files can only be
generated with a proprietary windows app...

It's open source, and LMMS uses the original rendering code: http://sourceforge.net/projects/drumsynth/ ...but whatever. I just thought a drumsynth with a pile of presets to start from would make more sense than one without.

Yeah but is that SF page just for the playback VST plugin, or the actual software for creating .ds files? Or is that the same thing? Will it compile on Linux/OS X? The last the topic came up, I was left under the impression that .ds files can only be created with the proprietary windows app, even if they can be played back with open source plugins.

I'm just saying, and I may be mistaken here, but if there's no easy cross-platform way to create .ds files, then it's not very convenient or useful for a large part of our users - we could just as well offer the existing .ds files as a sample pack or something, yielding the same functionality.

IMHO the main appeal in a drum synth is the ability to create and tweak (possibly in realtime) your own sounds... if that is lacking, then the synth is nothing more than a glorified, possibly CPU-wasting, sample player. And yes, that applies to a lot of existing "drum kit plugins", especially VST's... a proper drum synth should offer something more, something that isn't doable with simple sample playback. (The same actually applies to all synths, to a degree... again, IMHO).

If I'm mistaken and creating new .ds files is possible with free cross-platform tools, then sure, supporting .ds makes sense (but then we already do that, don't we?)

[softrabbit]

Perhaps, or just an instrument container instrument. We'll want to tweak every AFP individually anyway, what's keeping us from making a container which gives us assignable notes?

Structural changes in the core (sounds dangerous) and waiting for a stabler time?

I'm thinking I'd most likely want different samples of the same sound on the velocity axis, with pretty much the same tweaks, sending to the same channel. Plus possibly some round-robing thing going on, stuff like that. Sounds logical to me to have it in one plugin. Assigning notes happens on the other axis.

[Sti2nd]

I wouldn't have focused on drums, just the sampler. If this drum sampler turns out to only be made up of one drum synth it is only 1% better than the Kicker, or make that 0%, I don't have MIDI controls.

[diizy]

On 12/18/2014 10:17 PM, Raine M. Ekman wrote:

Structural changes in the core (sounds dangerous) and waiting for a stabler time?

To be clear: there's already so much large, ambitious stuff going on (a bit on hold right now, but still going on) so it's not exactly the best time to implement features like this...

I'm not exactly sure how invasive measures this idea would require, but at the very least, I don't think we have any easy way currently of "nesting instruments", or having instrument plugins load other instrument plugins (remember, in the context of LMMS, a VST is not an "instrument plugin", it's just an external software that is communicated with by an instrument plugin, ie. Vestige).

Maybe I don't know anything, maybe implementing it would be totally easy, but I still think it'd be better to wait for a more stable time to do this, when we don't have so many other big changes being made...

That said, I can see lots of potential for interesting things with the idea of nesting plugins. Think of an effect plugin that allows you to load parallel FX chains, or maybe split the signal with a crossover and apply different FX chains to each sub-band... there's definitely potential here, just the timing isn't the best possible for starting work on it.

[musikBear]

could be this could have a broather scope? Take a look at zasfx preset 'drums' (or sf-soundfonts-drums) This is in essence a drumkit Each sample is allocated to its own note. All is played in default pitch Now- what if theese samples wasent in-build, but was exchangeables The implementation could be that the preset loads a folder of samples, and these samples are then distributed over the various keys With one stone lmms would have both user-drumkit and sampler-playback abillity I got this idea from answering this forum-thread http://lmms.io/forum/viewtopic.php?f=15&t=1581 -and i then looked for similarity in hub what do you think?

[tresf]

Zasfx is quite unique. Most instruments don't have the capabilities to do as you are describing and assign a completely separate sound to each key.

Asside from that, I think what you are describing is really the same thing we are discussing above.

[tresf]

As far as a preset loading a folder of samples, that assumes we have a way to bundle the two... We dont have bundling support yet, but yes, it would eventually make sense in the design of this feature.

[Reaper10]

I'm working an idea for a drum machine / sound design plugim.

[Spekular]

@reaper10 I'm fairly certain we already have an issue/issues for this. Therefore I think it'd be better if you waited until your idea was done before posting, and posted it there.

[Reaper10]

that's what I'm doing.

[Reaper10]

Impact Zone plug-in #2134