Understood, yeah this would be a cool feature for sure. Although I think it would be better to get implemented in a new arpeggiator project. But who knows, let's see.ladybugs wrote: Wed Apr 22, 2020 5:53 pm I don't know about Roland arranger keyboards, but RealGuitar...
OK, now I see the problem. For some reason MFX plugin doesn't get playback start/stop events from host and behaves just like host is stopped. I will look into it. Probably when I did my code alignment with hardware version, I broke something here...QuantumState wrote: Tue Apr 14, 2020 1:12 pm I went back to version 2.2.8 of MFX for Logic Pro, it turns out that the following versions have sync failures where it is most noticeable with the default `` BEAT '' option, oddly enough it seems that the yellow dot indicator seems to scroll below the sequencer. once you stop playing, continue browsing a little more, it doesn't restart at first, in vst version it doesn't happen, in version 2.2.8 it is stable.
Synchronization also fails when in the Logic Pro options the option `` buffer interval '' with value `` large '' creates different types of synchronism, especially when you select another track where the main bluearp is not, in short ... a series of errors I'm not willing to test where it fails and where it doesn't, I'm sticking with version 2.2.8 ... for now ...
I think this great software should improve the simplest things. Less can be more. And synchronism is the heart of arpeggios, if that fails ... the arpeggio is dead. With Arp Avenger via VST3 opening from Patchwork, or Nora ... They are perfect ... instead, I have to find these errors that make it not work as it should. I think Bluearp is really improved in the VST version, but for Logic Pro there are not many users who use it and that is why they do not complain ... a sadness ... it is a shame because it is great software. A cordial greeting!
File permissions. I think the .ini file is in the same folder where the .dll is. Writing in this folder (Default VST2 folder which is often in c:/Programs) is allowed only to administrators. You can right click the ini file and set permission to something like "Write to everyone". Than the settings can be saved. I had this problem too.Ghost Dog wrote: Wed Apr 22, 2020 2:41 pm In my case, the second instance of BlueARP always scales back to 100% when re-opening a project (Win 7, REAPER 6.08).
At first I couldn't get it to even switch to a different skin permanently, but, running REAPER in admin mode solved that. Apparently, the first and second (technically, they're 5th and 6th) line in the config file are for the chosen skin and scale respectively and it works if the project has one instance, but the second one (and all the rest as well, if there's more than one) always reverts back to 100% scale.
Why?
I was asking why the second instance reverts back to 100% scale (I understand things regarding file permissions).Stirner wrote: Thu Apr 23, 2020 5:23 amFile permissions. I think the .ini file is in the same folder where the .dll is. Writing in this folder (Default VST2 folder which is often in c:/Programs) is allowed only to administrators. You can right click the ini file and set permission to something like "Write to everyone". Than the settings can be saved. I had this problem too.Ghost Dog wrote: Wed Apr 22, 2020 2:41 pm In my case, the second instance of BlueARP always scales back to 100% when re-opening a project (Win 7, REAPER 6.08).
At first I couldn't get it to even switch to a different skin permanently, but, running REAPER in admin mode solved that. Apparently, the first and second (technically, they're 5th and 6th) line in the config file are for the chosen skin and scale respectively and it works if the project has one instance, but the second one (and all the rest as well, if there's more than one) always reverts back to 100% scale.
Why?
Which version of bluearp? For 2.2.12 it would be really weird, cause it stores ini in this place:Stirner wrote: Thu Apr 23, 2020 6:09 am ...
I was asking why the second instance reverts back to 100% scale (I understand things regarding file permissions).
Not that it's terribly important, but, the post you quoted was actually mine.graywolf2004 wrote: Thu Apr 23, 2020 7:13 amWhich version of bluearp? For 2.2.12 it would be really weird, cause it stores ini in this place:Stirner wrote: Thu Apr 23, 2020 6:09 am ...
I was asking why the second instance reverts back to 100% scale (I understand things regarding file permissions).
C:\Users\<username>\AppData\Roaming\BlueARP
I did this to solve permissions problem, this folder should be writable.
2.2.11 stores ini next to BlueARP.dll.
According to symptoms you describe, for some reason it can't save value to ini, that's why next instance doesn't see this changes. Can you open ini file in notepad and check if it has changed (you will see gui_size = 0 for 100% or gui_size=1 for 125%). If it didn't, you can change it manually as a workaround
What version do you use?Ghost Dog wrote: Thu Apr 23, 2020 7:23 amNot that it's terribly important, but, the post you quoted was actually mine.graywolf2004 wrote: Thu Apr 23, 2020 7:13 amWhich version of bluearp? For 2.2.12 it would be really weird, cause it stores ini in this place:Stirner wrote: Thu Apr 23, 2020 6:09 am ...
I was asking why the second instance reverts back to 100% scale (I understand things regarding file permissions).
C:\Users\<username>\AppData\Roaming\BlueARP
I did this to solve permissions problem, this folder should be writable.
2.2.11 stores ini next to BlueARP.dll.
According to symptoms you describe, for some reason it can't save value to ini, that's why next instance doesn't see this changes. Can you open ini file in notepad and check if it has changed (you will see gui_size = 0 for 100% or gui_size=1 for 125%). If it didn't, you can change it manually as a workaround
The ini file has indeed changed, so that's not an issue.
The issue is this: the second instance that you insert (actually, all but the first one), disregards the scale written in ini file (but it does't disregard the skin choice, which is good). The first inserted one opens with the skin and scale factor set in the ini file.
I got the idea. I don't want to implement such thing in bluearp, cause it is quite specific use case and it wont fit nice with existing features. I'm not one of those developers who want to create 'ultimate do it all tool with unlimited possibilities'. I agree with phreaque, if I wanted to implement this, I'd create another plugin. If you are so passionate about this and have some tech background - maybe try to make one yourself. I use WDL-OL which implies C++ coding, but there are more friendly tools like SynthEdit to make VST plugins.ladybugs wrote: Wed Apr 22, 2020 4:06 pm FEATURE REQUEST: Fretting/picking
I posted this request about a year ago, but there was no reply. Trying again, respectfully, without wanting to hijack.
The keyboard is divided into 2 ranges:
- The "fretting" range, where you play to define the chord.
- The "picking" range, where you play to pick single notes from the chord.
In many cases, it's convenient if the picking range consists of white keys only.
How would it work in practice? As an example, let's assume fretting range is C2-B3 and picking range is C4-B6.
By holding down these keys in the fretting area:
C2 F2 Bb2 E3,
You'd get a mapping like this in the picking area:
C4 -> C2
D4 -> F2
E4 -> Bb2
F4 -> E3
So you can strum or arpeggiate arbitrary sets of notes. Or map them to percussion controllers, for that matter. And, what matters most, change the mapping instantly just by playing a different chord in the fretting area.
Do you think this feature could be added to Blue Arp, or does it sound more like a different midi plugin altogether? There's nothing like this available as far as I've been able to find out - and I searched quite a bit.
Yeah, I usually don't randomly check websites every day.graywolf2004 wrote: Thu Apr 23, 2020 8:20 am Current 2.2.12 doesn't have this issue - just tested in FL. I posted it here 2 weeks ago but only yesterday updated on my website. Probably this is the reason you didn't see it.
Previous 2.2.11 has this issue - just as you describe.
Perfect, I would rather you take the time to develop it stable, now that you have Mac mini you will be able to do the relevant tests, thanks and I hope that the next update is 100% stablegraywolf2004 wrote: Wed Apr 22, 2020 7:46 pmOK, now I see the problem. For some reason MFX plugin doesn't get playback start/stop events from host and behaves just like host is stopped. I will look into it. Probably when I did my code alignment with hardware version, I broke something here...QuantumState wrote: Tue Apr 14, 2020 1:12 pm I went back to version 2.2.8 of MFX for Logic Pro, it turns out that the following versions have sync failures where it is most noticeable with the default `` BEAT '' option, oddly enough it seems that the yellow dot indicator seems to scroll below the sequencer. once you stop playing, continue browsing a little more, it doesn't restart at first, in vst version it doesn't happen, in version 2.2.8 it is stable.
Synchronization also fails when in the Logic Pro options the option `` buffer interval '' with value `` large '' creates different types of synchronism, especially when you select another track where the main bluearp is not, in short ... a series of errors I'm not willing to test where it fails and where it doesn't, I'm sticking with version 2.2.8 ... for now ...
I think this great software should improve the simplest things. Less can be more. And synchronism is the heart of arpeggios, if that fails ... the arpeggio is dead. With Arp Avenger via VST3 opening from Patchwork, or Nora ... They are perfect ... instead, I have to find these errors that make it not work as it should. I think Bluearp is really improved in the VST version, but for Logic Pro there are not many users who use it and that is why they do not complain ... a sadness ... it is a shame because it is great software. A cordial greeting!
Thanks for your reply.graywolf2004 wrote: Wed Apr 22, 2020 8:30 amI got the idea. Never treated this as a problem, cause with my controllers (Novation Remove, Korg nano kontrol) you can assign a button to a single CC value (instead of sending 0 / 127 in toggle mode for example). So this way, each time you press a button, it just sends this CC value.kvmoore wrote: Mon Apr 06, 2020 9:43 pm Here's the GUI image I've created to support the above mentioned feature request.
To find out which CC value corresponds to param value, set control value in bluearp, on the bottom panel you will see:
P024: Sync = 4 / 40
In means that internal value 4 for sync (which is 1/16) corresponds to cc value = 40.
Can you assign the buttons this way on your controller?
I always do this way to assign chain switch to a row of buttons.
If it is unclear, I can make a quick howto video on this.
It is possible of course but it will require tons of new GUI controls, probably a separate screen for that. Cause you ask only for sync, but why not other settings? I don't want to clutter GUI this way, it is pretty dense already. For me the most elegant way to solve this would be to use separate midi plugin - midi cc converter. That would take different cc's and convert them to different values of one cc. Did you try to research - if there are suitable midi plugins for this?kvmoore wrote: Fri Apr 24, 2020 1:47 am ...
Thanks for your reply.
I understand what you are saying perfectly. However, that method would require a controller advanced enough to be programmable from the hardware itself to send out specific CC values from it's buttons, such as the ones you mentioned above. Unfortunately, I don't have a controller capable of being programmed from the controller itself to send out a specific CC value from a specific button. What I do have is a Novation Launchpad controller in which I must map the functions of it's buttons through the software and DAW. If my feature request was implemented, the separate sync parameter options would be mappable through BluARP to any button controller using any DAW such as Ableton Live and Cubase.
Yes. I have tried Bome's Midi Translator with an Akai MPK25 controller which did convert the CC value of it's buttons to whatever I specified (MPK buttons worked only in toggle or momentary mode sending values 1 or 127). This did work. However, using software midi filters like Bome's midi Translator added another layer in the midi chain and created additional jitter which meant the timing wasn't as tight when triggering in realtime. The purpose of this feature request is to allow BlueARP the ability to behave like the "Note Repeat" function of the Akai MPC using ANY midi controller and be able to instantly change sync quantization on the fly at the push of a button without the need for 3rd party midi filters.graywolf2004 wrote: Fri Apr 24, 2020 6:44 amIt is possible of course but it will require tons of new GUI controls, probably a separate screen for that. Cause you ask only for sync, but why not other settings? I don't want to clutter GUI this way, it is pretty dense already. For me the most elegant way to solve this would be to use separate midi plugin - midi cc converter. That would take different cc's and convert them to different values of one cc. Did you try to research - if there are suitable midi plugins for this?kvmoore wrote: Fri Apr 24, 2020 1:47 am ...
Thanks for your reply.
I understand what you are saying perfectly. However, that method would require a controller advanced enough to be programmable from the hardware itself to send out specific CC values from it's buttons, such as the ones you mentioned above. Unfortunately, I don't have a controller capable of being programmed from the controller itself to send out a specific CC value from a specific button. What I do have is a Novation Launchpad controller in which I must map the functions of it's buttons through the software and DAW. If my feature request was implemented, the separate sync parameter options would be mappable through BluARP to any button controller using any DAW such as Ableton Live and Cubase.
Submit: News, Plugins, Hosts & Apps | Advertise @ KVR | Developer Account | About KVR / Contact Us | Privacy Statement
© KVR Audio, Inc. 2000-2026
