Attn: Need a regroup and a recap!

[lazertronic]

I recieved a PM about a couple of items that a user would like to see implemented into the product.

1. Graphing the EQ curve in the software per patch.
2. Metering levels along FX chain in software.

I know number 2 is out of the question as MIDI does not allow us to retrieve and display that information, and he has been informed as such.

I also told the user that EQ graphing would probably be one of the last implementations of the first full release of the product as we are trying to get the editing part down first to get something to the users that they can use!



I have noticed that we have been kinda slacked in getting things done. I understand that we are doing this out of the kindness of our hearts, and in our spare time that takes away from family and life in general. I just wanted to kinda get a regrouping as to who is actually doing something with this project, and what they have accomplished or discovered at this point in the game.

I myself have read through the MIDI implementation, and it makes sense, and the layout is actually rather nice! I believe the only trouble that we will probably have is with the check summing, as well as the GUI interfacing. Those knobs are going to be a pain in the ass. Anyways, I do have a semester of Java programming experience (not much huh?), and would like to contribute some programming if I can (I'll give it my best), but don't have a compiler. I am familiar with the Microsoft Visual J++ environment, so if someone has any idea where I can get this or something similar (either very cheap or free if possible) it would be helpful to me!

Once I find out what we can work with as far as GUI implementation (i.e. knobs, sliders, buttons, textboxes, etc, I could start working on a GUI layout as well. I want to try to stay away from the Boss layout as much as possible. I know it would make it easier for the users, but I think that even the Boss GUI could use a little work! Seems to be kinda cramped and such.

So post here if you are currently working on the project, what you are working on, and what you have accomplished or discovered while working on this project so we all have a better idea of what is going on, and what other people are doing, so we don't have 20 people doing the same thing, but maybe a little differently. If need be, we can form groups to accomplish certain tasks.

The reson I am going into this is because I believe with a little organization, and maybe even some group work, we can accomplish our goals with this project much faster, and make everyone happy that we have a (free) tool to use with our new toys!

[MrSleepy]

HI Lasertronic

I dont see the checksum as a problem.
It uses the standard Roland checksum

checksum = add address bytes
checksum = add data bytes

checksum = (80h - (checksum & 0x7F)) & 0x7F

Roland would seem to have been using this checksum for some time as its the same a used by an older sound module that I have the manual for.

The GT8 editor I have written (Delphi PC only) does not apply any checksumming..and still controls the GT8 okay.
I'm not sure if the checksum is only used for bulk transfers.

Programming the GUI will be a real pain.. I know how to write vcl's in delphi and it takes time...no idea how the java equivalent will work.

I have also be wrestling with
1) upload details to PC...set GUI accordingly..then relay changes to GT8...

2) Have PC keep a copy of patch data...load and update GUI..send to gt8 at start of session..and the save any changes to data on PC ( this does have the advantage of not having to decipher messages from GT8 or sysdumps. It means that the user can save the patch from the buffer to where the want by the BT8 front panel....and woukld be significantly easier to implement.

Rob

PS... Does the patch level potentiometer on the GT have a midi memory location. I can find the memory loacations for almost everything apart from that.

[fredo]

Rob, what you did with your editor is great !! I'm amazed !! I love the way you recreated the GT-8 display ! How did you do that ?

I'm affraid I have not enough spare time to go that fast on my Java project. I currently have somp components working fine (with nice knobs, pressing the pedal switches the effect on and off and changes the led status). I also implemented drag and drop for the stomps to change fx-chain order. Anyway I still have a lot of work to do before the architecture is stable enough to start group work.

That beeing said, i really do think that we can share resources for the graphic concern. I mean, whatever the project will be (Java or Delphi or both) we will need an icon and a splash screen, images for simulated amps and stomps and so on.

I decided to call my project "geeboss", find it sounds cool and stands for "Graphic Effect Editor for BOSS". So anyone providing an icon and a splash for that will be blessed !! I know there are PhotoShop gurus around here... come on ! I was thinkin of a smooth and simple font like the one used here http://cocoon.apache.org/ to write "cocoon". Maybe with the top bar of the first "s" going over the seccond and the bottom bar of the seccond going under the first... I want to keep the "g" lowercase.

Rob, if you want to use geeboss as well, you can go of course ! I think at this stage having two parallel projects is not that bad since we need to do a lot of work on our own before the code is clean/stable enough to allow "team programming". So let's work side by side and share what is sharable. What do you think ?

Fredo.

[fredo]

PS... Does the patch level potentiometer on the GT have a midi memory location. I can find the memory loacations for almost everything apart from that.
Patch level @ is 0E 04 (page 28 of the chart).

Fredo.

[MrSleepy]

Hi Fredo


I think that sharing the intellectual data that we find on our GT8 voyage is very important.

I wrote the GT8 Editor as a way of
1) realising exactly what the GT8 can do...and how to do it...cos the manual is crap and I've almost found it easier to work from the midi implementation upward.
2) discovering the interactions betwween the GT8 front panel and how it controls the data in the temp buffer.
3) Good to get back to delphi..the last year has mostly been in embedded C on 8051 and arm based mcu's.
4) Working out a plan of attack for the project.


As In......
I have also be wrestling with
1) upload details to PC...set GUI accordingly..then relay changes to GT8...

2) Have PC keep a copy of patch data...load and update GUI..send to gt8 at start of session..and the save any changes to data on PC ( this does have the advantage of not having to decipher messages from GT8 or sysdumps. It means that the user can save the patch from the buffer to where the want by the BT8 front panel....and woukld be significantly easier to implement.




I am currently favouring the latter option. It gives us the GT8 as a scratch pad for our program. I know that initially the users will want to load that killer patch into the GT8 editor from the GT8 and then tweak. But I think it will be easier (for us) to do it without recourse to patch dumps etc. If the users create a must have sound...they can swap our settings file and load that..then save it from the GT8 front panel from the temp buffer...which is much easier than messing with sys dumps etc.

Rob

[MrSleepy]

PS... Does the patch level potentiometer on the GT have a midi memory location. I can find the memory loacations for almost everything apart from that.
Patch level @ is 0E 04 (page 28 of the chart).

Fredo.


d'oh... 8O



Rob, what you did with your editor is great !! I'm amazed !! I love the way you recreated the GT-8 display ! How did you do that ?


I cut up the fancy outer box an scanned it.

Rob

PS Have we decided on a Java environment to use... Or are the rest of the group sat in the slow lane :D

[fredo]

Rob,
I agree we should avoid asking the user to go to bulk transfer mode since it is long and blocks the unit. Anyway i was thinking of a slightly different approach : i want to use RQ1 commands to get the current temp buffer status and keep sync between the editor and the GT8.
I was actually thinking of using the sysex format as file format for the software, like GT-Manager and GS-Editor do. That would allow users loading patches from the site directly in the editor... My idea was to have a model object of a patch, decomposed in effects and parameters. Each object is capable of loading itself from sysex data and to transform itself to sysex data. We need the ObjectModel->sysex part to drive the GT-8 from the software, so the reverse way is not much more work is it ?
Well this is very Object Oriented I know, and I'm not sure it suits Delphi programming very well...

Fredo.

[fredo]

I cut up the fancy outer box an scanned it.
You could not do that to your 8 !! Poor beast !
No, seriously, the LCD display is awesome, is that a component from Delphi or did you write it yourself ? If you have images for all the displayed characters, i'm interrested...


PS Have we decided on a Java environment to use... Or are the rest of the group sat in the slow lane Very Happy
Well i made several posts about the GUI concern... I hate the slowness of SWING so I turned to SWT. What I achieved with the knobs and stomps is as smooth as what you can do with native implementations like yours. I don't think SWING could do that. SWT has support for Windows, Linux and Mac OS so it works for me. My config is JDK 1.5 + SWT 3.1. I use Eclipse 3.1 as a dev environment. All that stuff is free so I think it's cool !...

Anyway this does not mean I impose Java as a dev language ! I consider my work as a prototype to test the feasibility, but you Rob did a great job that proves as well that you got a working solution !...

BTW, I have made a request on sourceforge for the geeboss project yesterday. I have to wait a few days to get an answer...

Fredo.

[MrSleepy]

Hi Fredo


The LCD is a VCL that I downloaded from torry
called TLCDLabel v.1.6....
It is for D5 so I had to re write parts of the code to enable its use in D7.
D7 does not support design and runtime property designers pages in the same package anymore due to the lack of "proxie.dll" due to Borland licence restrictions.

It does not use bitmaps..it uses matrixes like a standard LCD.


At the moment I'm looking at the file/data structure and how the sysex will fit into it...it seems logical to make the sysex the basis for a record as it should have all the memory locations that Boss think need to be included.

DElphi is very object(component) orientated (as well as being strongly typed) so to create a object type would not be hard.

Rob

[MrSleepy]

I've also re evaluated the GUI approach that I am using.

I could keep it as it is , and make the LCD a 4 x 16 so that the fx settings can be altered via it (and put the effects order as a seies of icons across the bottom with drag support for the order)

using a 4 x 16 will nmake it much easier to fathom than the 2 x 16 that the GT8 has.

or take azn approach similar to Guitar port in which the effect/preamp/speaker ect ,takes up the middle space of the window..again with the FX1 & 2 routing across the bottom


My idea was to have a model object of a patch, decomposed in effects and parameters. Each object is capable of loading itself from sysex data and to transform itself to sysex data. We need the ObjectModel->sysex part to drive the GT-8 from the software, so the reverse way is not much more work is it ?

Hi Fredo.... I've been pondering over a sysex ..and apart from being scary 8O 8O It seems that an awful lot more data than just the page 21 onward patch data is transferred. I have columns of 605 wide characters for the 03 01 00 00 memory area for harmonist scales etc.
I know that under a sysex..once the base address ( 03 01 00 00) has been sent...the memory is auto incremented upon the next data char until the F7 EOX is reached..then the preceeding checksum is validated...but I still have 4438 lines of F0-----F7 data..... :(


I'm now realising how large the record/struct will have to be...

My Head Hurts.


Rob..


PS You wrote about the XML setup file for the gs-10(?)...could you email it to me please... rob(at)robredding.com

[lazertronic]

DAMN! That editor is kinda cool!

I agree that the 4x16 LCD wouldn't hurt for programming.

I kinda wanted to have the editor work with bulk dumps and such... it makes for much easier programming and arranging for people who set up differently for different gigs... (might just be me).

GT manager did this well. Being able to move patches around, copy, paste, and start fresh ones and just download what you need. With the help of the bank extent option, it lends itself perfectly to the roaming guitarist!


I also found something of interest in the MIDI implementation about the meters that I said would be impossible to monitor! I was wrong... upon looking closer at the MIDI Imp, the meter data for all 13 effects in the chain as well as the In and Out all have thier own memory locations! So this could be a possibility as a feature further down the line.

I would like to settle on Java as a dev environment, or atleast for the realeases, for the simple fact that it will lend itself to just about any OS platform that the users decide to use. I know that most people here are probably using the PC, but I'm sure there are a few, if not quite a few, that use the Mac OS environment considering it's use in the musical field.

Keep up with the great work guys. And please, keep the board posted on what you are doing, and accomplishing!

P.S. Fredo... I'll work on your spash screen and Icon for you.

[Absolute_Zero]

Re OSX - do a poll, I bet it's much less than you seem to think.

[fredo]

Geee ! It makes me cry to see how Bill gat us all.... Not event one Mac user over 25 GT-8 owners.... that's a shame....
--- edit ---
We have 1 Mac user over 28 !
-----------

Lazertronic, thk you in advance for the upcoming splash and icon ;-).
No one told anything about "geeboss"... do you guys like that name ?

About sysex file, yes, a complete dump is quite a big file : each patch adresses from 00 00 to 1E 00 which is about 7680 bytes * (140 user + 200 rom) + system area + quick fx + temp buffers !! It's a lots of bytes ;-).
But in a first step, we have to concentrate on the 7680 byte that make a patch configuration (wich is, I agree, a big deal already !).

I also think that patch copy/paste/move is an important feature, even if the GT-Librarian coming with the GT-Pro will do that. My idea was to have a tree view in the editor representing the patches in the unit : 2 roots = user and rom. Then one node per 10-bank group (35 siblings are to much) the one node per bank then on node per patch. We can use drag and drop to move / copy / swap patches.

About meters, i'm not sure each meter point has it's own adress (unless I missed something). The metter address (01 05 00 00) only is one byte wide. The value stored in here is the current metter point. As i wrote here http://www.bossgtcentral.com/modules.php?name=Forums&file=viewtopic&t=3374 I ran a test on that value and it actually changes the metter point real time which means if your unit is in metter view, the vu-meter will show the point you set via Midi. Well even if that will not allow us to display the meter VALUE on the editor screen, we can implement a feature that allows user switching the metter point watched on the GT-8 by clicking on the GUI.

Fredo.

[fredo]

Hi Fredo.... I've been pondering over a sysex ..and apart from being scary Shocked Shocked It seems that an awful lot more data than just the page 21 onward patch data is transferred. I have columns of 605 wide characters for the 03 01 00 00 memory area for harmonist scales etc.
I know that under a sysex..once the base address ( 03 01 00 00) has been sent...the memory is auto incremented upon the next data char until the F7 EOX is reached..then the preceeding checksum is validated...but I still have 4438 lines of F0-----F7 data..... Sad

Well a few more things about sysex and dump. Rob if you want to work with smaller amount of data, you have to dump a single patch (when in dump screen change start and end of dump to be TEMP->TEMP for ex)=> you should be able to retrieve all the dumped data in the "patch" table of the MIDI chart.

Lazertronic, when I worte
I agree we should avoid asking the user to go to bulk transfer mode I did not mean not to implement patch management in the editor. The thing is that the DT1 command allows us to write any value in any patch => we can send patch configurations to the 8 without puting the unit in "bulk load" mode. In the same way, the RQ1 command allows us to read any value from any patch => we can get the 8's current config without asking the user to go to "bulk dump" mode. This all can be transparent to the user.

Fredo.

[Absolute_Zero]

If OSX gets more than 5% I'd be suspicious. That's more Steve's fault than Bills.

[Absolute_Zero]

Take my point?

So far we've got 44 for Windows, 1 who should've voted Windows and another who dual boots Linux/Windows.

In my humble opinion...

MrSleepy should continue with his promising Delphi version... as should the Java dudes with theirs.

Just share what you learn, graphics etc, and compete on features. The language differences between us, to my mind, make it pointlessly unproductive to start learning a new language/paradigm/environment at this stage.

If there was a C || C++ || VB || .NET effort proceeding, I'd be slinging code too... that and the fact that I'm waiting for a GT-Pro.

But if I can help in anyway (sans hardware), just ask.

[Absolute_Zero]

Sorry, misread it... 1 vote OSX