BlueARP VST Arpeggiator development - let's discuss! (Apple M1 ready, 4K)

[ENV1]

Thanks for the update.

I didnt have time for very intensive tests yet, but what i did test so far seemed to be working exactly as it should.

Except for one thing.

Check out this WAV.

As you can hear, it transposes up fine, but when it transposes down there is sort of a double-note thing going on. This happens every so often. Not sure if there is a pattern to it, to me it seems to be happening at random.

BlueARP was set to init-defaults (i.e. the way it comes up when loaded) except of course for the sequence and the enabled latch function. Host was VSTHost, latest version.




PS: (FeatureRequest)

Whilst playing around with sequences i realized that it would be extremely nice to have an option to 'transpose on wrap'. (As opposed to transpose immediately.) That way you can program your sequence, enable latch, press a key in the middle of the sequence, and BlueARP will transpose only (and at the exact moment) when the sequence wraps/restarts. This would be especially useful in situations where you dont program everything via a pianoroll as it forces transpositions to always be spot on regardless of when you press the key. Im sure you know what i mean.

[graywolf2004]

Here's how you do it: first, keep an internal copy of song position and make it survive from one process-block to another. Then at the beginning of a block, check vstTimeInfo for whether transport is playing...

Thanks for detailed explanation. This is almost exactly the way I tried to do this and it worked, but the only problem - if you have lagre audio buffer (512 samples +), I didn't find the way to shift outgoing MIDI notes inside the block. So as a result you have note timing error up to latency/2 at best. If it's more than ~10 ms, it becomes noticeable. And I prefer not to have feature at all than to have a buggy implementation. Maybe use some internal timing? I need more time on this. I know, somehow it's possible even with high latencies, I checked with Kirnu and it works there.
PS. Post filter keys are actually "post input filter". So it's a key list which is an input for the arp engine. Master transpose happens after arp, so in should affect only Note Out. And it does, just checked. Maybe better to call them "Before input filter" and "After input filter"?

This thing thing is actually very nice.. it appears to be great for driving Dolphin (which I never bothered to give a sequencer).. quickie clip: http://www.signaldust.com/files/cheese.mp3
Definitely something I'll try to use in real tracks too.
pattern-seq <3

Nice demo! I'm currently finding my way through FL Studio performance mode with external controllers. I assigned foot pedal to arp latch setting and it works nice. Wanted to upload youtube demo, but will postpone it to next weekend.

Thanks Mystran, it's indeed an "order algorithm" matter but unfortunately there is no option, at least certainly no easy one, that gives both pitch and pitch descending together, eg all keys available on both sides of an held key. I'll try to figure out whether it's possible at all later.

Oops. Really, I have "as played" option, but not "as played, desc". It's easy to implement, I'll add it.
What you describe looks more tricky. If I got you right, you want your 1st key to be 1st pressed key, and for keys 2..5 you want to distinguish whether they are to the left or to the right of the 1st key. So order algorithm may for example look like this:
k1 - 1st pressed key
k2 - pitch k2 > k1
k3 - pitch k3 > k2
k4 - pitch k4 < k1
k5 - pitch k5 < k4

So say if you pressed (in order) A5, E5, C6, F5 your key list will be
k1: A5
k2: C6
k3: -
k4: F5
k5: E5

It's techically possible to implement such algo , but I don't have an idea how to call it, except "algorithm 1". Can you explain it (and your playing technique) in the same way?

ENV1 I'll check it and respond later, have to go now. Some questions to clarify - did you play keys live or recorded inside your DAW? If recorded, quantized or not? Restart option - on beat or on key?

[eidenk]

Graywolf, the held key isn't held by one of my fingers, it's held by the software and the arp patterns runs from it "forever", does my request makes sense in this context? As for a name for such a mode I'd perhaps call it free or absolute since it wouldn't restrict the use of any key unlike all other modes do as far as I can see.

[ENV1]

Some questions to clarify - did you play keys live or recorded inside your DAW? If recorded, quantized or not? Restart option - on beat or on key?

B3 held via latch.

Transpose via latch/keytap.

No keys permanently pressed.

[graywolf2004]

ENV1 OK. It makes more sense. I'll look into it. Do you mean 1 weird note at 0:09 of your wav? Yes, sounds like a double note. This is because of that maximum allowed step trigger latency. Here it behaves a bad way. On the contrary, if I'll remove it, it won't work when input notes are quantized (had this issue before). Need to think more of it.
Regarding your request - did you try to set inp.quantize to 16 steps? It should do nearly the same.
PS. What synth is this, if you don't mind? Sounds nice

eidenk Well, honestly still not clear. You can use "as played" order algorithm and press chord in any key order you like. Why doesn't it work for you?

[eidenk]

Well, honestly still not clear. You can use "as played" order algorithm and press chord in any key order you like. Why doesn't it work for you?

When "as played" mode is selected and there is a held note, pressing on any other key does nothing, the pattern carries on playing from the held key as root.

What I'd like to is be able to press any key while a note is held and the pattern carries on being played with the newly pressed key as root. If that's what is supposed to happen in "as played" mode, then it doesn't work here indeed.

"By pitch" and by "pitch descending" do what I want but only on one or the other side of the held note.

[ENV1]

Do you mean 1 weird note at 0:09 of your wav?

Yep, the bit that almost sounds like a strum.

Regarding your request - did you try to set inp.quantize to 16 steps? It should do nearly the same.

Actually it does exactly what i wanted.

Thanks for pointing this out, its perfect.

What synth is this, if you don't mind? Sounds nice

Not sure if i can say this here without being chastized (lol) but its the mighty Arturia minimoog, one oscillator, square 50%, PWMed by the filter envelope. (No FX, no compression, not even a limiter.) Soundwise my personal favorite by far because i cant even find a trace of the software-typical synthetic flavour in its sound.

[mystran]

Here's how you do it: first, keep an internal copy of song position and make it survive from one process-block to another. Then at the beginning of a block, check vstTimeInfo for whether transport is playing...

Thanks for detailed explanation. This is almost exactly the way I tried to do this and it worked, but the only problem - if you have lagre audio buffer (512 samples +), I didn't find the way to shift outgoing MIDI notes inside the block. So as a result you have note timing error up to latency/2 at best. If it's more than ~10 ms, it becomes noticeable.

Yes, but this has absolutely nothing to do with transport playing or not. It's the same in either case, unless a host uses shorter blocks while transport is playing (but most of them don't).

Remember vstTimeInfo refers to the data at the beginning of block. It doesn't matter when during your process-functions you call it (unless the host is seriously broken), it'll always refer to the beginning of block. As a corollary it's useless to get the time-info more than once per block, since you should always get the same data again and again.

The implication is that your plugin never "sees" any time intervals shorter than one block. If you want timing better than the block-boundaries, you have to use the beginning-of-block data (from vstTimeInfo) to calculate deltaFrames values for the mid-block events (and use the deltaFrames values of incoming events).

[hyperborea]

@ greywolf2004

I just found out about this GREAT instument you are working on and took it for a first spin.
All I can say is : I really love the possibilities it has and the way it can be used.

My compliments to you and thanks for sharing this.

Madeleine

[Evan]

graywolf,

Is this application skinnable? Are you open to suggestions on GUI refinements?

[graywolf2004]

graywolf,
Is this application skinnable? Are you open to suggestions on GUI refinements?

Yes, but later. Before New Year I want to make an offcial release, and there's a lot of another stuff to do (manual, tutorials). After that, I'll consider skinning.

[graywolf2004]

mystran It looked like process() is called also after each incoming midi note, but only in playing state. But maybe you're right and I messed something up with timing and time offsets.
PS. Thanks for detailed explanation, I'll look at it more carefully when I finish with more critical things.
Addition: I wasn't quite right. When playing, process() is called also on each 16th note start, so some blocks are shorter. It doesn't happen when stopped, of course (FL Studio 10).

[graywolf2004]

ENV1 One thought. Can you check the following to locate the error:
1. Try to reduce gate to say 95%. Will the dbl note bug still be there?
2. Reduce gate to 1%. Will it make any sound?

My guess is - it happens if arp sends out extremely short notes. Or when previous note off and next note on are not separated (come right one after another).

[ENV1]

Will check.

(Not today, but i should find an hour tomorrow.)

Will report back as soon as i got around to it.

[ENV1]

GateTime at 95%: Double occured somewhere between beat 255 and 258.

GateTime at 1%: Yes, sound still there.


Anything else you want me to try, just let me know.