GB-303 Bug Fixes, Feature Requests, Open Source. (Page 2 of 11)

playing:
1. Most important problem I noticed is when playing in song mode it has a small delay when it goes to the next pattern, which makes midi sync etc. impossible. This in my opinion is the first thing that needs to be fixed.

2. moving between "song mode" en "pattern mode" also creates a delay in the sound, this seems like the second thing that needs looking into to make it fully functional.

Saving: saving is possible but it requires the knowledge of exactly how.

Creating new patterns in song screen works, but requires knowledge of how again.

The program does not remember pot settings, which is not an error. this is not implemented as the manual says it saves only the function you assign to the pot. not the parameter.

Changing a pattern = change pattern number in song mode, press start on pattern so it starts playing, prees start to stop playing but notice that the arrow is now next to the new pattern, the pattern with the arrow next to it is the pattern that you can adjust in pattern screen.

How to save exactly I'll have to check again tonight when i'm home from work

Edit: also, since in the first post is mentioned that the idea is running it on a flash cart with saving different and midi instead of the pots, would there still be a solution for us that have the GB-303 hardware.   since I think that only problem 1 & 2 I mentioned needs fixing for the hardware gb303 cart.
Then we still need a way to flash and we would have a functional GB303 device.

Last edited by Manukinuki (Jun 30, 2015 1:52 pm)

Ahh that makes more sense. Real-time CC control via the AVR?

Manukinuki: My understanding is there were less than 20 carts actually shipped, a large number of the owners wouldn't hold the hardware to re-flash these. This would be an awful lot of coding, in two forks of the code to be done by one person, for the sake of only a few. If we get more coders onboard then we will work though all the original hardware issues. For now, my intention is to produce a flash cart compatible version for the widest possible distribution. As the bugs are fixed it would be as simple as updating the asm files in the original source if you wish to re-flash your own original cart.

Biere: Waveform replacement will be something to address after the bugs are fixed.

I would love Furrtek to resume work on this or at the very least contact me. I understand priorities shift and he may no longer have the time or want to work on this but a snappy chat would speed up this whole process.

KeFF: Aira GB? If you want to submit some art I can roll it in.

Progress so far...

I've re-written the EEPROM handling routines to use SRAM instead. This is mostly complete, I need to re-write the 'format' routines to initialise a corrupt/fresh SRAM. Other than that, the SRAM port is complete. Already this will provide around a 20x increase in read speed and over 100x write speed.

I’ve bypassed the ADC (pot) input detection. I’ll have these routines instead use MIDI CC data passed into the GB. This also has the option to use multiple inputs to control all aspects of the waveform generation, not just 3.

Furrtek's code used 16kbytes of EEPROM. A standard cart is 32K. I’ll change the Save routines to use the full 32K and have it save every user input.

That is enough to keep me busy for now.

I have not uploaded it yet, I don't have a github logon. I will make one tonight and update my progress. I'd like to update once I'm happy with a code change though, not a half finished SRAM implementation. It would be useless for someone to try pick up from a semi-complete routine. If you prefer I can zip and email you the code as it is developed? Or just upload once I'm happy with an update. I'd do it now but the work gateway won't allow it.

Never used Github and my VCS is usually replicate my working folder and begin an updated revision of my code, time stamping each folder as I go. Not optimal but works for me. I just read the Github help page and seems pretty easy though most commands are shell based. I suppose there are GUI apps to do it on a windows PC?

So yes, please share any info you think I'll need on the git VCS.

"The easiest way to use GitHub on Windows
is unfortunately not supported by your OS. Upgrade to Windows 7 or newer."

Im running XP, I have 8 on my laptop and Ubuntu on my desktop but most work gets done in XP. The shell script examples are based in a Linux environment. It doesn't really matter, code development is what is important. I'll upload each iteration to my site and if someone wants it, or wants to put it up on Github they are welcome to do so.

If Github progress is that important I'll transfer it to my laptop and commit from there.

Update: No progress made last night, I had to catch up on a few orders and re-assemble my milling machine. I Should be good for a few hours tonight.

DSC has offered custom arduinoboy code to the project. His version incorporates external pots which can be used in place of the original hardware pots. Most people already have an arduinoboy so the mod should be relatively easy.