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

[Cyoon]

so is this the OS X update weekend?

[graywolf2004]

Thanks so much for looking into that 'chains' issue! Right now I'm just making sure the pattern begins on a bar of the song that's an even multiple of the chain length - not easy to keep up!
-

Hi. Sorry for long silence. I had working Saturday. Now spending second half of Sunday fooling around chains issue. Turned out to be more tricky than I expected.
Currently debugging in restart on = "beat" mode. BlueARP aligns it's step counter to PPQ (song position) from host. It's OK when you play single pattern, but with a simple chain like
(4 steps) - (8 steps) - (8 steps), sync = 1/16
2nd program (8 steps) starts from step 5. It's what you reported. So the solution is to calculate the offset = length of all previous steps.
restart on = "key" is even more trickier. There are two options:
1. Restart the whole chain when new key is pressed after all keys were released
2. Restart the whole chain only once when 1st key is pressed
Maybe it's better to add "1st key" option for 2nd scenario? Anyway, I'm fixing restart on beat mode first. The problem is that I added chains functionality after I coded the code MIDI logic and now it's time to re-check it and re-think some concepts.

Please forget about my point above re putting a different number of chains to make automation easier. I've seen the selector that lets you change it to 10 or whatever, and seen how to automate it with a knob or automation. Brilliant!

Yeah, this is the point . As for chain switching accuracy, check "chain quantize" parameter. When you set it say to 1 beat, it will switch chain on the exact start of a new beat. So you can switch it a little beforehead, quantize will make it smooth. Logic is the same as with "inp.quantize" for input keys.

[graywolf2004]

so is this the OS X update weekend?

Sorry, no updates this weekend. I didn't expect working Saturday . Now debugging core MIDI logic with chains, 2-3 hours I got before going to bed is not enough to finish it )

[glinkot]

Thanks Oleg! I understand what you mean about when to restart the chain - it's tricky. Perhaps we could define a 'chain restart key' (eg I could set it to the lowest or highest key on the piano roll) which we hit to restart the chain. And it would filter that keypress out and not pass it on or use it.

I had a play with Blue Arp this weekend, and it's really brilliant, you should be very proud.

Thanks

PS. Is there a version of the manual that mentions the 'scale' features? I gave it a try but the input and output keys never seemed to change to reflect a certain scale, so I think I'm missing something. The PDF manual I found predated that feature! I was trying to get the music to stick to the phrygian mode for some trancy goodness.

[graywolf2004]

Thanks Oleg! I understand what you mean about when to restart the chain - it's tricky. Perhaps we could define a 'chain restart key' (eg I could set it to the lowest or highest key on the piano roll) which we hit to restart the chain. And it would filter that keypress out and not pass it on or use it.

I had a play with Blue Arp this weekend, and it's really brilliant, you should be very proud.

Thanks

PS. Is there a version of the manual that mentions the 'scale' features? I gave it a try but the input and output keys never seemed to change to reflect a certain scale, so I think I'm missing something. The PDF manual I found predated that feature! I was trying to get the music to stick to the phrygian mode for some trancy goodness.

I'm halfway finished with chains. At least in restart on beat mode now I can chain programs of arbitrary length, and they a properly linked. Say I have programs 1-2-2-3 with lengths 2-5-5-4. When program 1 ends, program 2 starts from step 1. The same works with restart on key, but the whole chain starts on 1st key pressed.

While playing with it myself I discovered that making 'restart on key' program-dependent is not convenient. If you want it to restart on key - you want it for your whole session. So it's logical to make this setting at least bank\project-dependent. The same - for input and output range.

There's nothing yet in the manual about scales. It's still quite experimental thing.

[rasmusklump]

Is the issue that BlueArp goes completely out of sync at higher latencies looked at ?

Cjeers
Alex

[graywolf2004]

Is the issue that BlueArp goes completely out of sync at higher latencies looked at ?

Cjeers
Alex

I know about this issue and it's in my todo list, but with lower priority.

[rasmusklump]

strange, don't get me wrong, I love bluearp over all the comnmercial arps, but how can such a crucial thing as timing have a low priority ?

[graywolf2004]

strange, don't get me wrong, I love bluearp over all the comnmercial arps, but how can such a crucial thing as timing have a low priority ?

I don't see any reason why to set latency > 256. When under 256, timing is not an issue. So I don't consider this as a crucial thing. And I don't have a solution for it right now, it requires more invertigation. I already spent some time trying to fix it, no luck.

[sinkmusic]

I don't see any reason why to set latency > 256.

For what's it worth (i don't have timing issues and enjioy BlueARp) :
Of course, everyone is trying to get the lowest latency possible, but there are several situations why latency > 256 can be needed :
- When working on an older computer, increasing the buffer size will allow to have more tracks, more plugins instances, more effects, and still have a smooth playback ;
- Some plugins behaver/perform better with higher latencies : the great Acon plugins (equalize, reverbate, etc), for instance, use far less CPU if you have a bigger latency setup.
- Some hosts with a less than average PDC can create less glitches while playbacking if a bigger latency is set, mostly if you use a convolution plugin in your session or something like REainsert ;
etc
- If your computer setup is not configured for real time production and performance, but optimized for mastering, but still sometimes you want to have fun and fool around with FL or BlueArp, etc.

Really, only my 0.2 cents

[Spitfire31]

If you're playing in realtime, you certainly won't use >256.

And if you're mixing at higher latency with the arp being triggered from a track, why not just render or freeze? Provided that BluArp handles non-realtime rendering correctly, of course…

/Joachim

[graywolf2004]

I'll post question to the development forum, maybe will get some help there. Anyway, now I need to finish what I started with chain sync and timing issues.

[graywolf2004]

Update: BlueARP v2.10
Windows
http://www.graywolf2004.net/files/2/Blu ... _v2.10.zip
OSX
http://www.graywolf2004.net/files/2/Blu ... _v2.10.zip

There are many changes in this version, so better use it separately (copy it to new folder and rename BlueARP.dll to BlueARP_v2.10.dll)
Changes:
1. Improved timing for program chains. Chains are now sticked together regardless of each program length, arp core calculates appropriate time offsets for each program in chain. Next program will start at step 1 strictly after previous program last step.
2. Improved timing for 'restart on key' mode. While in 'restart on beat' you stick to host song position, in restart on key mode BlueARP will start the whole chain after you press the 1st key. Also chain will restart when you press a key after all keys were released.
3. There are 'Pos:' and 'Beat:' labels in info panel. Pos shows song position reported by host, 'Beat' shows internal beat counter. In restart on key mode it may differ from Pos. BlueARP uses 'Beat' value to calculate a step. Looking at it will help you to understand how it works. For example when you have a fragment of a song looped in you DAW and this loop recycles, Pos will revert to 0 while the Beat will continue incrementing (it's about restart on key mode)
4. 'input quantize' and 'chain quantize' value lists have changed, now they are fraction of a bar. For example, input qualtize = 1/4 means quarter of a bar or 1 beat. Input quantize also works in restart on key mode. If you have a chain and want it to start smoothly (synced to a beat), set input quantize = 1/4 and press chord keys a little beforehead. The chain will start strictly at the next beat.
Chain quantize works the same way, but it affects chain switching. If you set it to 1 bar and switch chain in the middle of a bar, the actual chain switching will happen strictly at the beginning of the next bar.
5. I made parameters like 'input quantize', 'input range', 'output range' global, so they are stored at bank\project level. If you change any of them, it will affect all programs in the bank. Say if you configured input range C0-D5 for bass part, no need to re-configure it for each program you use. Program-dependent parameters are marked with (*) sign.
I'm not sure it's a final solution. The other idea is to group bank-dependent params together into 1 block. But on the other hand, current order of params is designed according to signal flow and it's logial. Do you have any other ideas?
6. Fixed bug with input range (wrap).

PS. For those of you who looked into the manual - there's a signal flow diagram at page 8. Was it useful to get the basic idea how bluearp works? If so, I'll update it to reflect program chains and other changes.

[Cyoon]

Nice one, graphics seem to be fixed on OS X thx!

[phreaque]

Support our best developer, he deserve an award! Urra Oleg