Supplementary:
You can relax Oleg, this time it was not BlueARPs fault.
Turns out it was VSTHost that was responsible for this starting at odd positions - in fact the error was even saved into the performance.
(The exact cause still eludes me, but if i should find out i will let you know.)
Sorry for the false alarm.
BlueARP VST Arpeggiator development - let's discuss! (Apple M1 ready, 4K)
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
ENV1 You're doing a good job testing it for errors and I appreciate this. Restart on key function was kind of tricky, and probably with latest fixes I broke something there. It's hard too keep all this stuff in mind already. But I have all the source code history and can find where it got wrong. I'll check restart on key this weekend. If it worked before, the issue shouldn't be hard to fix.
OK... just saw your next message. Anyway, I really appreciate your efforts...
OK... just saw your next message. Anyway, I really appreciate your efforts...
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Glad youre taking it the right way. 
So i did some checking, and i think i at least know now what triggers the problem. Whether the 'culprit' is BlueARP or VSTHost is still unclear, (in other words it might be BlueARPs fault after all), so maybe you should give it a go yourself and draw your own conclusions. Try this:
- Open VSTHost
- Drag BlueARP DLL into VSTHost
- Open BlueARPs UI and enable RestartOnKey
- Press a key to check where the pattern starts
- If its starts on Step1, click the metronome icon in the toolbar
- Set BPM to 110
- Press a key
The sequence should now no longer start at Step1.
- Leave BPM at 110 and delete this BlueARP instance
- Open a new instance and enable RestartOnKey
- Press a key
Sequence should still start at the same (wrong) position.
- Save the whole thing into a performance
- Close VSTHost, restart it, reload the performance
Sequence should still start at the same (wrong) position.
(Thats what i meant by 'error is saved into performance'.)
- Set BPM from 110 to 120
BlueARP should no longer function at all.
- Set BPM back to 110
BlueARP should function again.
Note: To remedy the problem at any time, use the cogwheel icon in the toolbar. This allows you to disable and restart VSTHosts engine. (This also resets the 'Beat' counter to zero, like Rewind would do in other hosts.)
So i did some checking, and i think i at least know now what triggers the problem. Whether the 'culprit' is BlueARP or VSTHost is still unclear, (in other words it might be BlueARPs fault after all), so maybe you should give it a go yourself and draw your own conclusions. Try this:
- Open VSTHost
- Drag BlueARP DLL into VSTHost
- Open BlueARPs UI and enable RestartOnKey
- Press a key to check where the pattern starts
- If its starts on Step1, click the metronome icon in the toolbar
- Set BPM to 110
- Press a key
The sequence should now no longer start at Step1.
- Leave BPM at 110 and delete this BlueARP instance
- Open a new instance and enable RestartOnKey
- Press a key
Sequence should still start at the same (wrong) position.
- Save the whole thing into a performance
- Close VSTHost, restart it, reload the performance
Sequence should still start at the same (wrong) position.
(Thats what i meant by 'error is saved into performance'.)
- Set BPM from 110 to 120
BlueARP should no longer function at all.
- Set BPM back to 110
BlueARP should function again.
Note: To remedy the problem at any time, use the cogwheel icon in the toolbar. This allows you to disable and restart VSTHosts engine. (This also resets the 'Beat' counter to zero, like Rewind would do in other hosts.)
-
- KVRAF
- 2802 posts since 31 Aug, 2011
And heres the good news:
I just checked backwards through the releases to see where the trouble began and found that the problem does not exist in 1.08 beta.
With this build i can set the BPM to whatever i want (even with a key pressed, i.e. while BlueARP is playing the sequence) and BlueARP never restarts the sequence on a step other than Step1.
So we have at least one build where the RestartOnKey implementation seems to be rock solid. Im sure this should give you a clue as to what the problem might be.
I just checked backwards through the releases to see where the trouble began and found that the problem does not exist in 1.08 beta.
With this build i can set the BPM to whatever i want (even with a key pressed, i.e. while BlueARP is playing the sequence) and BlueARP never restarts the sequence on a step other than Step1.
So we have at least one build where the RestartOnKey implementation seems to be rock solid. Im sure this should give you a clue as to what the problem might be.
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
ENV1 Thanks for your time. Actually you spent more than I did. Yesterday I did a quick test in FL, found this bug and fixed it. At least now BPM doesn't go to '-' with restart on key. I'll post an update in several hours. Want to test more with BPM change and improve the manual.
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
Checking the menu item "Engine / Wave Recorder / Player Sync" in VSTHost will allow you to use the player buttons (full rew / rew / stop / start / pause / fwd) to control the current transport position, even if no audio file is loaded for playback. If it's unchecked, VSTHost simply increments the current playback position ad infinitum.ENV1 wrote:Note: To remedy the problem at any time, use the cogwheel icon in the toolbar. This allows you to disable and restart VSTHosts engine. (This also resets the 'Beat' counter to zero, like Rewind would do in other hosts.)
"Until you spread your wings, you'll have no idea how far you can walk." 
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
Update: v1.11 rc2
http://www.graywolf2004.net/files/BlueARP_v1.11rc2.zip
Changes:
1. Fixed RestartOnKey bug reported by ENV1
2. Dots changed to down arrows for elements with menu
3. Improved manual
I didn't check tempo issue in VSTHost, probably it has the same reason, but no sure. Anyway bug in p.1 is critical so I'm posting the update as soon as possible. Still halfway done with color schemes.
I want to relese it in March, so I won't make any major changes before the stable release. Regarding manual - will also add some instructions how to set up BlueARP in different DAW's. Anything else I missed?
ToDo list for the next month:
1. Check it with Cakewalk Sonar (bug reported by dazarz)
2. Finish the manual
3. Color schemes (low priproty)
4. Create 'factory' bank. Anyone to contribute?
http://www.graywolf2004.net/files/BlueARP_v1.11rc2.zip
Changes:
1. Fixed RestartOnKey bug reported by ENV1
2. Dots changed to down arrows for elements with menu
3. Improved manual
I didn't check tempo issue in VSTHost, probably it has the same reason, but no sure. Anyway bug in p.1 is critical so I'm posting the update as soon as possible. Still halfway done with color schemes.
I want to relese it in March, so I won't make any major changes before the stable release. Regarding manual - will also add some instructions how to set up BlueARP in different DAW's. Anything else I missed?
ToDo list for the next month:
1. Check it with Cakewalk Sonar (bug reported by dazarz)
2. Finish the manual
3. Color schemes (low priproty)
4. Create 'factory' bank. Anyone to contribute?
-
- KVRAF
- 7024 posts since 28 Apr, 2004 from france
-
- KVRAF
- 2802 posts since 31 Aug, 2011
Ah...now thats ingenious!arakula wrote: Checking the menu item "Engine / Wave Recorder / Player Sync" in VSTHost will allow you to use the player buttons (full rew / rew / stop / start / pause / fwd) to control the current transport position
Very much appreciated in deed because thanks to this info i can now finally use VSTHost like a full fledged DAW by using PolyGrid (which doesnt work right when VSTHost is in 'constantly running' mode) as a Pianoroll!
(BTW, as someone who uses both VSTHost and SAVIHost intensively, (practically every day), there are like a ton of things i always meant to bring to your attention. Is there any particular place here on KVR where i can bother you with my feedback?)
I hate to be the bearer of bad news again, but its not fixed in VSTHost.graywolf2004 wrote:Update: v1.11 rc2
http://www.graywolf2004.net/files/BlueARP_v1.11rc2.zip
Changes:
1. Fixed RestartOnKey bug reported by ENV1
See this GIF. After BPM change, BlueARP restarted around Step13/14.
And as you can see, it also always sort of tries to 'catch up' shortly after the restart, meaning its like skipping steps or executing them very rapidly.
-
- KVRAF
- 1940 posts since 16 Aug, 2004 from Vienna, Austria
You got a PMENV1 wrote:(BTW, as someone who uses both VSTHost and SAVIHost intensively, (practically every day), there are like a ton of things i always meant to bring to your attention. Is there any particular place here on KVR where i can bother you with my feedback?)
"Until you spread your wings, you'll have no idea how far you can walk."
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
ENV1. No problem, thanks for your patience, animated GIF is very helpful. "Step: -" means that for some reason it goes negative. I'll check it this weekend. Should be some flaws in step calculation logic.
-
- KVRist
- 90 posts since 15 Jan, 2013 from Bremen, Germany
hi, im new here
graywolf, you did a great plugin.
is it possible to automate patternchange via automationclip in fl studio?
if yes, can you explain how ?
graywolf, you did a great plugin.
is it possible to automate patternchange via automationclip in fl studio?
if yes, can you explain how ?
The good old 80s never come back
a old FLStudio nerd
a old FLStudio nerd
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
ZXOxo67 I thought of it too, but didn't implement yet.
At this point I see possible solutions:
1. Make BlueARP respond to program change messages
2. Make pattern change visible for automation. But the problem here - it's not convenient to set program num with a knob/slider, since it's 64 values total, you need to do very fine adjustments.
A better solution imho is automating program change for a certain range (user confugurable). This way you can assign a knob which will scroll through programs 0..3 for example. If you have any other ideas, you're welcome
Currently I'm about to fix timing bugs reported by ENV1 and then I can switch to this.
At this point I see possible solutions:
1. Make BlueARP respond to program change messages
2. Make pattern change visible for automation. But the problem here - it's not convenient to set program num with a knob/slider, since it's 64 values total, you need to do very fine adjustments.
A better solution imho is automating program change for a certain range (user confugurable). This way you can assign a knob which will scroll through programs 0..3 for example. If you have any other ideas, you're welcome
Currently I'm about to fix timing bugs reported by ENV1 and then I can switch to this.
-
- KVRian
- Topic Starter
- 805 posts since 15 Apr, 2012
Here's the quick update.
http://www.graywolf2004.net/files/BlueARP_v1.11rc3.zip
Changes:
1. Bugfix for timing issue in VSTHost (reported by ENV1)
ENV1 Not sure I fixed all, but at least it should fix something. I couldn't reproduce exact the same thing (with Step: -). In my case, after I change BPM, it restarts on some other step (not 1), and this step is constant until you change BPM again.
The issue was simple - I relied on SamplePos for better timing, but since you change BPM, you need to adjust all sample offsets. In 1.08, I relied on PPQ only. I changed it back to PPQ for this offset, since it doesn't make any difference here.
http://www.graywolf2004.net/files/BlueARP_v1.11rc3.zip
Changes:
1. Bugfix for timing issue in VSTHost (reported by ENV1)
ENV1 Not sure I fixed all, but at least it should fix something. I couldn't reproduce exact the same thing (with Step: -). In my case, after I change BPM, it restarts on some other step (not 1), and this step is constant until you change BPM again.
The issue was simple - I relied on SamplePos for better timing, but since you change BPM, you need to adjust all sample offsets. In 1.08, I relied on PPQ only. I changed it back to PPQ for this offset, since it doesn't make any difference here.