Hello all and a question!!

35 posts / 0 new
Last post
brookesy
brookesy's picture
Hello all and a question!!

Hello everyone, I'm new to system exclusive messages which is a reason I've joined this forum and I have a question.....hmmmmmm(clear of throat)

I have a Roland VG-88 Version 2 which is not too dissimilar from the Boss GS-10 which is on the Audio hardware section of this site.

I've been examining the midi implementation of the GS-10 in the actual manual and comparing it to the Implementation in BC manager and the sysex strings are different.

Examples for the Delay Parameters: BC Manager 1st then the Manual

DD: On/Off  F0 41 10 00 63 12 09 00 07 00 val cks-1 6 F7  

** ** 07 00  00 00 00 01

DD: Type  F0 41 10 00 63 12 09 00 07 01 val cks-1 6 F7

** ** 07 01  00 00 00 01

DD: Delay Time  F0 41 10 00 63 12 09 00 07 02 val cks-1 6 F7

** ** 07 02  00 00 00 01

DD: Delay Time Fine  F0 41 10 00 63 12 09 00 07 03 val cks-1 6 F7

** ** 07 03  00 00 00 01

DD: Tap Time  F0 41 10 00 63 12 09 00 07 04 val cks-1 6 F7

** ** 07 04  00 00 00 01

DD: Feedback   F0 41 10 00 63 12 09 00 07 05 val cks-1 6 F7

** ** 07 05  00 00 00 01

DD: High Cut Filter   F0 41 10 00 63 12 09 00 07 06 val cks-1 6 F7

** ** 07 06  00 00 00 01

DD: Effect Level    F0 41 10 00 63 12 09 00 07 07 val cks-1 6 F7

** ** 07 07  00 00 00 01

In the VG-88 implementation the beginning of the string would look like this:

F0 41 00 00 27 12 with (from the manual) ** ** 02 6E  00 00 00 02

can someone explain to me in laymans terms why the second half of the string (00 00 00 01) is ignored and what determines ** ** to be (I presume) 09 00.

The 6 before the F7 and leaving off the 00 00 00 01, is this BC manager specific to start checksum?

Be gentle

Thanks in advance

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

** ** is how Roland's manuals indicate the variable first two bytes of a four-byte parameter address.
So for instance in "** ** 07 00  00 00 00 01" (for the GS-10's DD: On/Off) the asterisks can be substituted by the first two bytes of any user patch (06 00 - 06 63), ROM patch (07 00 - 07 63) or the temporary patch (09 00). (In my ini file for the GS-10 I use "09 00", so this pertains to the temporary patch.)

The last four bytes ("00 00 00 01" in the example above) indicate the size (in bytes) of the parameter (i.e. 1 in this case). Roland's "DT1" ("12H") messages (which we're dealing with here exclusively) don't include a size indicator, but only the data bytes themselves (so just one byte in this case).

In BCL (the language for programming Behringer's BCF2000 and BCR2000), Method StartByteIndex defines the method that the BCF/BCR2000 will use to calculate the correct checksum byte (immediately before F7), as expected by the receiving device.
For Roland's DT1 messages, Method must be cks-1.
StartByteIndex indicates the index (position) of the first byte in the message that is taken into account in calculating the checksum, with the very first byte of the message (always F0) having index 0. For Roland's DT1 messages, StartByteIndex should always indicate the first byte of the address, i.e. "6" for the GS-10 and the VG-88. (This isn't the case for all Roland devices, since the length of the "Model ID" byte sequence varies.)
See section 14.6.3 in BC MIDI Implementation.pdf (obtainable from https://mountainutilities.eu/bc2000) for further details.

Hope this helps,
Mark

brookesy
brookesy's picture

Hi Mark,

Thanks for the quick reply.

First of all, my goal is to use my BCR2000 to control the same parameters that the Vedit (VG-88 Editor) does.

I read your answer and I understand it for the most part  'The last four bytes',I struggle with. For the case of the VG-88 it is '00 00 00 02'  data bytes=2???.

I connected the output of the VEdit to BC Manager via Midi Yoke 01. Turned the Delay Feedback Knob and it read like this.

$F0 $41 $00 $00 $27 $12 $0C $00 $00 $00 $00 $07 $03 $0B $02 $0E $04 $00 $00 $0A $00 $00 $03 $02 $05 $0A $00 $00 $00 $03 $00 $03 $00 $00 $00 $00 $01 $0F $01 $0F $01 $0F $01 $0F $01 $0F $00 $0C $03 $02 $03 $02 $03 $02 $03 $02 $03 $02 $03 $02 $05 $00 $05 $00 $05 $00 $05 $00 $05 $00 $05 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $0C $00 $0C $00 $0C $00 $0C $00 $0C $00 $0C $00 $00 $00 $00 $06 $04 $00 $00 $06 $04 $00 $01 $03 $02 $06 $04 $00 $00 $00 $01 $00 $00 $00 $00 $00 $00 $01 $04 $01 $04 $01 $04 $01 $04 $01 $04 $00 $07 $00 $01 $01 $00 $F7 $F0 $41 $00 $00 $27 $12 $0C $00 $02 $00 $01 $03 $01 $08 $01 $04 $01 $04 $01 $04 $00 $07 $00 $01 $01 $00 $00 $01 $00 $00 $00 $00 $00 $00 $00 $02 $00 $00 $00 $00 $00 $00 $01 $09 $03 $02 $04 $0B $05 $00 $04 $06 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $0A $04 $00 $01 $00 $00 $01 $09 $00 $09 $00 $0A $00 $00 $00 $00 $00 $00 $02 $08 $02 $0D $00 $08 $50 $F7 $F0 $41 $00 $00 $27 $12 $0C $00 $03 $00 $00 $03 $01 $0E $00 $00 $00 $00 $00 $04 $01 $0C $00 $02 $00 $07 $03 $02 $00 $0C $00 $08 $00 $00 $02 $0D $01 $04 $06 $04 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $78 $F7 $F0 $41 $00 $00 $27 $12 $0C $00 $04 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $00 $00 $00 $0D $02 $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $0C $06 $00 $00 $00 $00 $00 $00 $00 $01 $00 $00 $00 $01 $00 $00 $00 $0E $00 $00 $00 $00 $00 $00 $06 $04 $00 $00 $00 $0C $00 $00 $00 $04 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $07 $0F $07 $0F $07 $0F $07 $0F $07 $0F $07 $0F $07 $0F $07 $0F $00 $01 $00 $01 $00 $01 $00 $01 $35 $F7 $F0 $41 $00 $00 $27 $12 $0C $00 $05 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $00 $07 $08 $00 $00 $03 $02 $00 $00 $05 $06 $02 $0D $04 $07 $05 $05 $04 $09 $05 $04 $04 $01 $05 $02 $00 $00 $00 $00 $00 $00 $00 $01 $00 $02 $00 $03 $00 $04 $00 $05 $00 $06 $00 $07 $00 $08 $00 $09 $5D $F7

 Whereas, I connected the output of the GS-10 Manager to BC Manager, again turned the Delay Feedback Knob via Midi Yoke 01 and it read like:

$F0 $41 $10 $00 $63 $12 $09 $00 $07 $05 $32 $39 $F7 as it should and exactly like you explained.

Why such a large string? If I can acheive the goal like you have with the Gs-10, I will upload it to your site if I can get some headway with it that is.

 The GS-10 Manager is absolutely amazing BTW, the amount of control and visual feedback is stunning. (I'm seriously thing of buying one after seeing this).

A big pat on the back for you, sir and thank you again for the help. Opening new horizons for me, I can tell ya!!!

Regards

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

The MIDI Implementation document of the VG-88 v2 (VG-88_V2_MI.pdf), states on p. 6 that for patches "all data is transmitted as nibble data". A nibble is a 4 bit-value, i.e. a half-byte (either the upper of the lower part of a byte). So the VG-88 communicates a patch parameter consisting of eight bits as a sequence of two nibbles. I think the upper nibble (the most significant four bits (bits 4-7)) is sent first, followed by the lower nibble (the least significant four bits (bits 0-3)). So e.g. a parameter value of $7E is sent as $7 $E. However, of course MIDI can only send whole bytes, so each of these nibbles is actually sent as a byte, with the upper four bits being 0. So the two nibbles $7 $E are actually being sent as the two bytes $07 $0E.
The reason for this seemingly superfluous byte-splitting is that a MIDI data byte can only use the lowest seven of its eight bits (in other words, its range is restricted to 0-127 = $00-$7F). This is because a byte in which the uppermost bit (bit 7) has a value of 1 is a MIDI status byte (e.g. the $F0 or $F7 of System Exclusive messages). Curiously, there are few (or no?) VG-88 patch parameters that can have values higher than 127, but at least this is how it works...
Anyway, this is why most VG-88's patch parameters indeed have a value of 2 ("00 00 00 02") in the Size column. (A few Assign parameters have size 4.)

The BCR2000 can send various portions of a parameter value as separate bytes; e.g. to send the upper nibble, use val4.7; to send the lower nibble, use val0.3. (See section 14.6.1 in BC MIDI Implementation.pdf for all the options.)
So I think a BCR2000 encoder definition for the VG-88 patch parameter at address 0C 00 00 00 (i.e. the first parameter in the first user patch) could look something like:
$F0 $41 $00 $00 $27 $12 $0C $00 $00 $00 val4.7 val0.3 cks-1 6 $F7
Of course you'll also have to set the encoder's range (Value 1 and Value 2) correctly.

The block of data received from the VG-88 that you included in your post consists of five SysEx messages, namely for areas starting at 0C 00 00 00, 0C 00 02 00, 0C 00 03 00, 0C 00 04 00 and 0C 00 05 00. Each of these five messages doesn't contain data for a single parameter, but for a range of parameters; in other words, these messages look like "bulk dump" messages; I don't know the VG-88, so I'm not sure how that happened.

Yes, I'm still very proud of GS-10 Manager, even more so than of BC Manager, even though BC Manager has become much more popular.
However, I'm not sure whether you would want to buy a (second-hand) GS-10 at this stage (unless very cheaply):
1. It's about twelve years since the GS-10 came out, so better-sounding alternatives should be available, both software and hardware.
2. Reportedly, no Windows 8 (or later) driver is available for the GS-10's USB connection (for both MIDI and audio). (This is one of the reasons I'll be sticking to Windows 7 for a looooong time...!) Of course it will remain possible to control the GS-10 via its "real" MIDI I/O sockets, and to capture its audio output from its Digital Out socket, but still...

Good luck!
Mark.

brookesy
brookesy's picture

Thanks alot Mark for the very useful information, I will decipher your message the best I can smiley  and I'll get back to you.

Have a great day!

Simon

brookesy
brookesy's picture

Hi Mark,

I'm happy to say, that I have succeeded in my quest to control the VG-88 with the BCR2000.

But first, I'd like to comment on the 'Thanks for nothing by never_again', I also was having problems saving and transferring presets during the time I was figuring out how to program the BCR for the above project. I reloaded the latest firmware again but this time using the utility in BC Manager and now it works perfectly. I had previously used the Behringer app which did not complete the full dump (shame on them) and then MidiOx which worked but something wasn't quite right ie. Windows 7(32) came up with error messages while loading BC Manager. I thought it was an incompatability issue but works fine now. 

So people the message is simple, make sure the BCR is working as intended. I know it's frustrating to lose presets in this manner but vent your anger elsewhere not to someone who has created a program that does way more than the manufacturer even publicised and for free!!!!! and one more thing it works a treat!!

Off the soapbox....

Mark, where was I... right....I have a better understanding of nibble data now, thanks to you and the Kenton Control Freak manual.

VG-88 Delay Time parameter on the USER patch BANK 1 PRESET 1:

$F0 $41 $00 $00 $27 $12 $0C $00 $02 $68 val4.7 val0.3 cks-1 6 $F7 with the encoder's range set at  Val 1.  0  and val 2.  715 as stated in the manual.

It's easy when you know how!

The next thing I need to know is how to write this as an .INI file. especially this part $0C $00 $02 $68 val4.7 val0.3. Is it possible to change the preset number in this info header  $0C $03 patch preset 4 etc to save time?

[MODEL]
ProgramName=BC Manager
ProgramVersion=2.6.0
ManufacturerName=Roland
ManufacturerID=41
ModelName=VG-88
ModelID=00 27
DevicePosition=
MinDevice=
MaxDevice=
DefaultDevice=00
Command=12
AddressLength=
ChecksumMethod=1
ChecksumStart=6
FileVersion=2.0.0
FileAuthor=
Comment=

I've left the one's out that I'm not sure about.

Best Regards and thanks again for this huge help

Have a great day!

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

Have you looked at section 18 of the BC Manager Manual? It discusses all the items in the ini file header.

ProgramVersion indicates the minimum version of BC Manager that is required to load the ini file. Since BC Manager 2.6.0 didn't introduce anything new concerning the ini file format, it's better to set this to 2.5.0, so that people still using BC Manager 2.5.0 can also open your ini file.

For Roland devices, DevicePosition must be BeforeModel.

MinDevice and MaxDevice determine the range of the Device ID that the end user will be able to select when he/she is assigning a parameter to a button or encoder. From the VG-88's manual and MIDI implementation document I gather that the VG-88's range is 1 to 32 as presented to a user setting the Device ID on the VG-88 itself, but internally this amounts to 0-31, which is 00-1F hexadecimally. So MinDevice should be 00 and MaxDevice 1F. (If you wish, particularly for private use, you can of course restrict this range, even to 00-00.)

AddressLength should be 4.

FileVersion, FileAuthor and Comment are basically up to you. (I'm not sure why you've chosen '2.0.0'. I wouldn't use this number to indicate the VG-88 "Version 2", if that was your intention. Instead, if the ini file is specifically for the VG-88 V.2, why not simply set ModelName to "VG-88 V.2" or so?)

So I think the header should look something like this:

[MODEL]
ProgramName=BC Manager
ProgramVersion=2.5.0
ManufacturerName=Roland
ManufacturerID=41
ModelName=VG-88 (V.2?)
ModelID=00 27
DevicePosition=BeforeModel
MinDevice=00
MaxDevice=1F
DefaultDevice=00
Command=12
AddressLength=4
ChecksumMethod=1
ChecksumStart=6
FileVersion=1.0.0
FileAuthor=Simon
Comment=

If I understand your question about "saving time" correctly, you're talking about putting part of the parameter address into the header. As discussed in the BC Manager Manual on p. 78 ("The Command field can specify ..."), you could add the common part of the address (the first byte or possibly the first two bytes) to the Command field; this would make the individual parameter definition lines shorter. However, I would advise against this, because it's a bit dirty and very confusing (for one thing, I think you'd need to lower the value of AddressLength accordingly). So I would simply put the full 4-byte address on each parameter definition line.

So for instance:
0C 00 02 6E | 00 - 64 | val4.7 val0.3 ;User Patch 1-1: Delay: Feedback

However, the above format is only correct for parameters with Size 2.
For parameters with Size 4 you need to include val8.11 and sometimes (depending on the maximum value of the parameter) val12.13 too.
For instance, I think the Delay Time parameter you mentioned should be defined as:
0C 00 02 68 | 00 00 - 0E 15 | val12.13 val8.11 val4.7 val0.3 ;User Patch 1-1: Delay: Time
... or (since this parameter's bits 12 and 13 are always 0):
0C 00 02 68 | 00 00 - 0E 15 | 0 val8.11 val4.7 val0.3 ;User Patch 1-1: Delay: Time
Note that MaxValue must be "0E 15" for this parameter:
In the VG-88 V.2's MIDI implementation document, this parameter's maximum value of 1813 (decimally) is written as 0715; "Table 'DD_DlyTime" (p. 18) makes clear that this is an "ordinary" 16-bit hexadecimal value. However, BC Manager expects two seven-bit hexadecimal values for MaxValue (in other words: two MIDI data bytes, with bit 7 always being 0): the first value is to consist of bits 7-13 of the original value, and the second value is to consist of bits 0-6 of the original value. So in this case, 0715 must be written as "0E 15". (You can use BC Manager's "MIDI data calculator" for conversions like this - that's what I did...!)
The reason BC Manager expects two seven-bit hexadecimals, is that Roland MIDI implementation charts usually describe a parameter's maximum value exceeding 127 as two seven-bit hexadecimals too.
Very tricky stuff! I can only hope you're still breathing...

Mark.

brookesy
brookesy's picture

Hi Mark,

$F0 $41 $00 $00 $27 $12 $0C $00 $02 $68 val4.7 val0.3 cks-1 6 $F7 with the encoder's range set at  Val 1.  0  and val 2.  715 as stated in the manual.

I wrote the above in BC Manager and tested and it worked perfectly, so do I really need to change it?

I was surprised because of what you said about it having a value of 4 instead of  2.

Just a thought

Simon

brookesy
brookesy's picture

Hi Mark,

I've retested, and yes it does work but only between values of  0 and 511ms  what I suspected after a rethink.

Above that it cuts the value in half.

Sorry about that and thanks for the reply BTW

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

Since I don't have a VG-88, I only "know" what I've read in VG-88_V2_MI.pdf:
On p. 14 it says that DLY TIME starts at ** ** 02 68 and has a size of 00 00 00 04, which fits with the fact that the next parameter, TAP TIME, starts at ** ** 02 6C.
Furthermore, the "DD_DlyTime" table on p. 18 specifies that Delay Time ranges from 0-1813 (decimally), with 0-1800 amounting to milliseconds (one-to-one), and 1801-1813 standing for various BPM-related values.

The encoder setup you've been using does modify Delay Time, but (if I was correct about the nibble order) only its most significant part. So clearly this encoder setup doesn't achieve the full 1 msec resolution and can't select all (or any) of the BPM-related values. And hence the weird behavior you're reporting.
Don't despair - you're getting there!

Mark.

brookesy
brookesy's picture

Hi Mark,

That is absolutely correct, I looked at this only a few minutes ago.  

I got to thinking that this parameter would be best split into two and change the relevant values.

Thanks again

Simon. 

brookesy
brookesy's picture

Hi Mark,

I tried the revised method and something is not quite right, the hardware is either showing the first value or the last value. Delay: Time    0  or  1813.

Regards

S

 

brookesy
brookesy's picture

That should have been minimum or maximum value. it was late!!!

brookesy
brookesy's picture

Hi Mark,

Problem Solved-

It should have been written in this order   0C 00 02 68 | 00 00 - 0E 15 | val4.7 val0.3 val12.13 val8.11

I suspected this from the previous  try  0C 00 02 68 | 00 00 - 0E 15 | val4.7 val0.3 when it managed 0-511ms.

Anyhow it works a treat and now it's time to build a super controller.

Also, I thought of a way of changing the preset by using Bome's Midi Translator but that's for another day.

thanks for all your help and best regards

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

Yes, when you mentioned you had managed 0-511 with your old setup, I too started suspecting there was something wrong with my idea that the most significant byte came first, but I couldn't quite figure it out - no wonder if the correct order is "val4.7 val0.3 val12.13 val8.11"! Dear oh dear...
I'm pretty sure that the VG-88 V2's MIDI Implementation document didn't explain this properly, so let's blame Roland shall we :-)

In any case you're now on top of things, and should be well prepared for any other surprises the VG-88 may have in store!

Good luck!
Mark.

brookesy
brookesy's picture

Hi Mark,

Well I thought I was.......
I have managed to control other presets using Bome's MIdi Translator Pro by switching the preset which is really great, but let's say that it's another preset where the DELAY is switched OFF. I manually switch the DELAY on.
I turn the knob, the VG-88 acknowledges the input data, it changes the parameter as normal but it turns the DELAY off.

Why?

I read somewhere (a while back) that people had problems with MIDI devices resetting themselves.

Have you any idea what's going on?

Sorry to be a royal pain.

Simon

PS. I wanted to send you a donation via the OBAN Method but my bank wants your address and your bank's address (for security purposes probably). Could you send them to me via E-mail? If not then I'll go down the Paypal route.

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

I don't know what's going on with the delay sneakily switching off.
It could simply be a bug in the VG-88. And are you sure Bome Translator isn't involved? (No "reset all controllers" MIDI message or so?)
Does it only occur once for a particular patch, or every time? I.e. what happens the second time you switch the delay on and then send a delay parameter?
Many MIDI devices (such as the GS-10 and the BCF/R2000) have a temporary patch/preset area that you can read from and write to, but curiously I can't find such an area in the VG-88 V2's MIDI Implementation document. I would guess that internally the VG-88 does use a temporary patch (how else could it function?) but that you just can't access it via MIDI.
So here's one rather wild idea: maybe when you manually switch the delay effect on, this affects the delay on/off setting of the temporary patch, and then the subsequent delay parameter switch causes the VG-88 to copy the whole memory patch (where the delay is still off) to the temporary patch. But I could be totally wrong.

Have you tried switching the delay effect on/off via MIDI?
VG-88_V2_MI.pdf, p. 12: ** ** 01 50  00 00 00 02  00-01  DELAY ON/OFF

The fact that your bank wants my and my bank's address might be for security purposes, but it may also be because they simply don't support IBAN (the whole point of IBAN is that no further data is needed!). And if that's the case, it also seems not impossible that a transfer from your bank to mine would suffer from some commission along the way after all. So it seems best not to torture ourselves with all the horrid details of a bank transfer, and simply use Paypal. Much appreciated!

Note: In a few hours I'll be going to a place without internet access for a week, so I won't be able to communicate during that time.

Mark.

brookesy
brookesy's picture

Hi Mark,

The bank supports IBAN, I had never heard of this before seeing it on your websites donate page. I went to my online bank account and it showed my own IBAN details and WIC no. which was something of a surprise. Nice to know. I'll send it by Paypal, no problem.

I've decided to sort out  the configuration file then afterwards check out other effects parameters to see if it happens on them as well. A week gives me plenty of time to do this so they'll be no interruption from me, promise ;O)

thanks again for the reply

Simon

 

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

From https://en.wikipedia.org/wiki/International_Bank_Account_Number I gather that the adoption of IBAN is still very much "ongoing":

Based on a 20 December 2011 memorandum, the EU parliament resolved the mandatory dates for the adoption of the IBAN on 14 February 2012. From 1 February 2014, all national systems for credit transfer and direct debit must be abolished and replaced by an IBAN-based system. This will be extended to all cross-border SEPA transactions from 1 February 2016 (Article 5 Section 7). After these dates the IBAN will be sufficient to identify an account for home and foreign financial transactions in SEPA countries and banks will no longer be permitted to require that the customer supply the BIC for the beneficiary's bank.

Given the above, I'm even more mystified why your bank said my IBAN account number wasn't sufficient. It might indeed be security, as you suggested, but I haven't read about that anywhere.

Anyway, your very generous Paypal donation has indeed reached me, so thank you very much for that!

How's the configuration file going?

Mark.

brookesy
brookesy's picture

Hi Mark,

Yes, it's pathetic really. This is typical of how things are done in the UK. You are treated like a moron because they think you cannot look after your own affairs. Another point to this is I couldn't proceed any further with the transaction until that obstacle had been dealt with. In other words another irritating brick wall....

The configuration file is coming on fine, I have done the Delay, Chorus and Reverb. I noticed that the FX section of GS-10 is an improvement on the VG-88, a few more extra parameters here and there. Yesterday, I completed the COSM guitar section which is quite comprehensive and the COSM EQ and Pan. The COSM Pan is quite exciting beacause you have real time control of the panorama of each string ( could you imagine that with a delay inserted! Mind blowing!!!)

Remember on reply 16 when I had the problem with the delay switching off?  I went to my home studio where I have more i/o (Steinberg Midex 8) and now works as it should. I also got it working very well with Bome's Midi Translator which means I can control other presets.

I'm a very happy at the moment...

Regards

Simon

brookesy
brookesy's picture

Hi Mark,

Can you tell me what is wrong with the following line

0C 00 00 18 | 00 00 - 12 C0 | 0 val8.11 val4.7 val0.3 ;PITCH

Here is the header just in case

[MODEL]
ProgramName=BC Manager
ProgramVersion=2.5.0
ManufacturerName=Roland
ManufacturerID=41
ModelName=VG-88
ModelID=00 27
DevicePosition=BeforeModel
MinDevice=00
MaxDevice=1F
DefaultDevice=00
Command=12
AddressLength=4
ChecksumMethod=1
ChecksumStart=6
FileVersion=1.0.0
FileAuthor=Simon Brookes
Comment=All refer to Patch 1-1

Regards

S

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

If I'm not mistaken, this line is wrong in two respects:

In the first place, the MaxValue parameters must consist of MIDI data bytes, i.e. bytes in which the highest bit ("bit 7") is 0.
To quote from the BC Manager Manual (p. 79):
If two bytes (separated by a space) are specified, these bytes constitute an MSB-first 14-bit value, i.e. with bits 0-6 of the first byte being bits 7-13 of the resulting value, and bits 0-6 of the second byte being bits 0-6 of the resulting value.

I chose this clumsy method because most of the Roland/BOSS MIDI implementation documents I knew specified MIDI data bytes too, but it was a tough decision.

Anyway, to find the correct representation you can use BC Manager's MIDI data calculator (opened via View -> MIDI in the main window): you specify the "normal" value under "Normal bytes", and then you'll see the converted value under "MIDI data bytes".
Thus it becomes clear that 12C0 must be written as 25 40.

The second problem with your line concerns the BCL section, "0 val8.11 val4.7 val0.3":
As you can see in the MIDI data calculator window under Normal bytes -> Binary, $12C0 amounts to 0001_0010_1100_0000 in binary form (I've added the underscores for clarity); so bit 12 is 1, which means that you have to use "val12.13 val8.11 val4.7 val0.3".

Mark.

Mark van den Berg
Mark van den Berg's picture

Oh wait, this is another of those horrid "Size 4" parameters.
So I suppose the BCL section should be "val4.7 val0.3 val12.13 val8.11", just as for Delay Time.
How could I forget, haha...

M.

brookesy
brookesy's picture

Hi Mark,
I've been completing the configuration file for the VG-88 as you know but I've been getting this message

Error: Value out of range

I've narrowed the problem down to these lines of text:

0C 00 00 18 | 00 00 - 12 C0 | 0 val8.11 val4.7 val0.3 ;PITCH

0C 00 02 20 | 00 00 - 12 C0 | 0 val8.11 val4.7 val0.3 ;PITCH

{BPM
0C 00 05 10 | 00 00 - 00 FB | 0 val8.11 val4.7 val0.3 ; BPM
}

Could you be so kind as to explain why? because they seem fine to me.
Best Regards
Simon

PS. I have just read your answer and I take it, this is the case for the BPM parameter as well

Mark van den Berg
Mark van den Berg's picture

Yes, BPM's "00 FB" should be similarly converted to "01 7B".
However, in this case only bits 0-7 (of the "normal" value) can be 1, so I think the BCL section could be simplified to "val4.7 val0.3 0 0". In fact, even "val4.7 val0.3" might work. But maybe I'm missing something here, so you'd better verify that either of these simplifications actually works. (Of course nothing prevents you from using the standard "val4.7 val0.3 val12.13 val8.11" anyway.)

Mark

brookesy
brookesy's picture

Hi Mark,

I think I've got it

From the Manual, hence the "val4.7 val0.3 val12.13 val8.11" the opposite way

*2 When transmitted, the lower byte is sent first. For example, the order for 1234H will be 34H and then 12H.

'So I suppose the BCL section should be "val4.7 val0.3 val12.13 val8.11", just as for Delay Time'.

Re. The Delay (Time) is actually written like this

'0 val8.11 val4.7 val0.3'  or  'val12.13 val8.11 val4.7 val0.3'

but I think the parameters in question should be written out as "val4.7 val0.3 val12.13 val8.11" because they are not tagged with the *2, with the conversion of course.

Is this the upper byte being sent first?

Simon

 

brookesy
brookesy's picture

IGNORE THIS

It should have been written in this order    val4.7 val0.3 val12.13 val8.11  or  val4.7 val0.3 0 val8.11 and this is the lowest byte being sent first.

brookesy
brookesy's picture

Hi Mark,

Another error message

DevicePosition expected

What does this mean?

Regards

S

 

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

I think this error can only occur when the line in the header that should start with "DevicePosition" starts with something else.
BC Manager is totally strict about the order of the lines in the header.
However, the header you mentioned yesterday is fine (I've just tested it!), so all I can think of is that you have accidentally swapped some lines in the header since then.

Hope this helps,
Mark.

brookesy
brookesy's picture

Thanks Mark,

I  had amended the line

ModelName=VG-88 with the V2

works fine now

Ssmiley

brookesy
brookesy's picture

Hi Mark,

I take it that FCB1010 Manager does not support the UNO chip? If it does, can the FCB1010 also output sysex?

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

No, FCB1010 Manager doesn't support the UnO chip. I never got round to buying the UnO chip, so my knowledge of it is practically zero.

Mark

brookesy
brookesy's picture

Hi Mark,

How do I send you the configuration file?

Can the BCR display (-) values eg. -50 -+50?

Also, if I have a parameter with a value of 9 ie a low number, can I spread this value across the full duration of the encoder(all LEDs). At present , it is only using a small section (7 - 10 o'clock, if you know what I mean! )

Thanks again

Simon

Mark van den Berg
Mark van den Berg's picture

Hi Simon,

Do you want your configuration file to be included in the installation package of the next version of BC Manager? If so, there's one "problem" with that: I'm not sure when I'll release the next version of BC Manager - this might be months away.
So for the time being it seems best to upload it to the user file section of this website (https://mountainutilities.eu/userfiles/b-control), so that people have access to it immediately.

Sadly the BCR can't display negative values.

To spread a small range across all encoder LEDs, use a low value for the Resolution parameter. The standard value is 96 values per full rotation, but you can try something like 8 or 16.
In BC Manager the Resolution parameter is editable via the General tab of the encoder dialog box. (It cannot be customized via your SysEx configuration file.)
See section 17.3 of BC MIDI Implementation.pdf for the full details on Resolution.

Mark.

brookesy
brookesy's picture

Thanks Mark for all your help, It's been quite enjoyable learning about this stuff and it really opens up the VG for new sonic possibilities. I'll probably upload a mapping at some point in the near future.

Regards

S