Plugin request: midi time-shift

[magnetophon]

I just discovered the wonderful time-shift feature of B.choppr. Could you build something like that for midi? That way any sequencer would gain an advanced swing function.

Thanks for considering!

[sjaehn]

Hi Bart,

do you talk about B.Choppr or about B.Jumblr (the sequencer-pattern delay plugin) ? Or do you mean the horizontal markers of B.Chopper which allow to set the size of each step?

[magnetophon]

Yes, I mean the marers in B.Choppr. I was making a shaker by feeding noise to B.Choppr, and used the markers to add some swing in various ways. Then it occurred to me you could also do this with midi, delaying or speeding up the notes as they come in. Of course for speeding up you'd need some latency in the plugin.

[sjaehn]

Interesting idea. I'll think about it how to do it.

[magnetophon]

Cool! Thank you!

[sjaehn]

I thought about it and combined your inspirations with those I had anyway:

Idea 1: In the present version, B.Choppr choppes an audio input and sends the result to an audio output. It wouldn't be too much work to additionally/alternatively/optionally generate a MIDI signal (MIDI CC, or maybe note/velocity). This midi signal would represent the slider value (times 127) at the respective time point. Also generation of CV is possible. I just did this with B.Shapr.

Idea 2: To make a B.MidiChoppr. Simply chop MIDI input signals (CC or note/velocity, or ...) and send them to MIDI out. And once again, a CV version is possible.

I think idea 2 is closer to yours.

Talking about the MIDI version. Not all of the controllers of B.Choppr will be needed there. Smoothing using attack, release, and shape type is redundant. Also dry/wet mixing doesn't make too much sense.

Please keep in mind, B.Choppr doesn't produce any delay! Really! Although it might sound like it.There are no buffers in the plugin. And therefore no latency. But the result may sound similarly, especially if you would use a MIDI version.

[magnetophon]

That would be really cool! The midi version would have latency, right? The whole point is to move notes in time!

[sjaehn]

If you set the level of step 1 to 0.00 then you will get a delay, because each step after a level 0.00 step will sound delayed. As the NOTE_ON will be sent delayed. This would be an intended effect. But delay is not latency. If the plugin would report the delay time as latency, a host would compensate this effect :-(.

[magnetophon]

I was thinking it should be able to move notes both later and earlier in time, so that's why it'd need latency.

[sjaehn]

OK, I understand. In this case we really talk about a time shifter or delay plugin. Not about a choppr. Therefore we are not talking about a MIDI version of B.Choppr.

You are right about latency for plugins which support negative delay. B.Jumblr is a delay plugin, but for positive delay only.

[magnetophon]

Yes, a midi time-shifter plugin would be a better description of what I want. Not sure what a midi chopper would do, I thought you where taling about the same thing.

[sjaehn]

A midi chopper would do the same as any other chopper plugin but on the midi signal instead of an audio stream. For both types of choppers: The input signal is time-dependently (or rhythm-depenently) cut into pieces.

The big difference between both would be: an audio chopper (like B.Choppr) is a post generator (synth or sampler or ...) plugin. A midi chopper would be pre generator. A midi chopper would cut each incoming midi note into a number of individual notes. And each individual note will be sent individually to the generator. So each chop will get its individual ADSR envelope. In contrast to a conventional (audio) chopper, where the audio signal is only wrapped once into an ADSR envelope by the generator before the chopper.

Even better you can hear the difference if you use a sample. Simply record a count "one - two - three - four". One number per second. Set host to 60 bpm, 4/4 beat. Set plugin to 1 sequence per bar, 4 nr of steps. If you create a symmetric 0.0 - 1.0 - 0.0 - 1.0 pattern in B.Choppr, you will hear "two" "four". In case of a midi chopper you would hear "one" "one".

Now change nr of steps to 3, size of step 1 to 50% of the whole sequence using the horizontal markers and make a 1.0 - 0.0 - 1.0 pattern. Using B.Choppr you will hear "one two" "four". Using a midi chopper you would hear "one two" "one". You know why?

And I think your problem to get a swing function can easily be solved in this way. (i) If you set nr of steps to (multiples of) 3, you can break down a quarter note into 3 triole notes. The same way you can also break down a full note into 16 hi-hat 1/16 notes. (ii) Add some swing using either the swing function or horizontally move the markers.

The advantage: I don't see any need to buffer data and cause latency using this approach.

(BTW, you can get similar results with step sequencers.)

[magnetophon]

Ah, of course, that is what you mean by midi chopper! That would be an interesting plugin for sure. Might as well include an arpeggiator with that wonderful scale UI of yours!

What I envisioned when I made the original request, but explained very badly, is:

• Input a stream of midi notes.
• Have a UI like the B.Choppr, that lets you create a "time-scale-graph" and a volume envelope.
• Now instead of chopping up midi notes, only move the start and end positions to match the time-scale graph. So you always keep the same number of notes.
• Multiply the velocity of each note with the value of the volume envelope at the time of that note.

So if you leave all the controls at default, the midi will pass trough unchanged. when you move the swing knob, the notes that start on the even subdivisions are delayed, for swing values bigger then 1:1 and moved forward in time for sing values smaller then 1:1. Same for note endings that fall on even subdivisions. Hence the need for a plugin with latency and a host with latency compensation.

Notes that fall between the lines are moved part of the way, by interpolating the time graph.
Smoothing using attack, release, and shape type is not redundant; it would give control of the levels of notes in between the grid lines. Dry/wet mixing indeed doesn't make sense, but it would be nice to have two amount knobs, one each for time and level. Set them to 0 and you have a bypass, set them to 50% and you get halve of the effect.

Does that make sense? To me it would be a dream come true in terms of flexible and nondestructive groove manipulation. It seems you have all the building blocks in place to make it happen!

Thanks for listening! :)

[sjaehn]

I start to like this idea. We are talking about a tool to stretch or squeeze incoming midi notes following a given pattern? Something like this?

[magnetophon]

Cool! I'm exited to hear you like it! My note reading is a bit rusty, but I managed to decipher it. Yes, that is exactly what I mean!

You didn't mention the velocity part of it, but I'll assume that it was clear and you like that facet as well. :)

[sjaehn]

Velocity is clear.

Features like the horizontal markers, sequences per bar, swing, auto markers, and number of steps can easily be used as well in the new project.

I wouldn't implement blend, attack, and decay in the first steps of development. I think a shape editor (like in B.Shapr) would be superior for the intended use for the notes between the lines.

A monitor displaying incoming and outgoing midi signals doesn't make too much sense. I would prefer a graphical representation of the steps instead (like in my previous post).

Therefore, there would be no need for a monitor switch anymore. Time and level can be implemented later.

Possible additional features which could be added step by step could be:

• A switch to choose between "change note length and position" (as shown in my last post) and "change note position only" (quarter notes will stay quarter notes, thus notes may overlap). And for completeness: "change note size only".
• A menu to choose the class of midi signal to manipulate (note only, or note + cc, or all midi)
• An option to set sequence size > 1 bar. Simplest way: 0.5 sequences per bar.
• An option to re-arrange step order. Like input step 1 will be sent out in 3rd position, whilst input step 3 will be sent out first. This can be implemented as a popup menu for each (output) step.
• An option to insert or remove steps for output. Maybe in combination with the re-arrange option. This could be used to convert a 3/4 beat to 4/4 by filling up or vice versa.
• Any additional idea ...

But first of all, the plugin core needs to be rewritten. Audio to midi. And this isn't straight forward, as audio (stream) and midi data (message + timestamp) are two totally different types of data. Especially, you can have more than one midi note at a point of time. And then I've to implement the time shift...

[magnetophon]

That all sounds great.

I don't think we need step removal or reorder. I cannot imagine a good use case, nor can I imagine an good UI for it, where you can predict the result of a certain setting. Maybe I'm just not visionary enough! :)

When you say audio to midi, you mean rip out the audio code and write midi code, right? There is no audio in the plugin we are talking about, right?

[sjaehn]

Right :-)

[sjaehn]

Just uploaded a first version to https://github.com/sjaehn/BSchaffl . Let us continue there.