It avoids them by minimizing realtime control 
Offline
Unsubscribe
BennVenn wrote:
Yes, I don't intend on recreating LSDJ. Instead I want to reproduce the missing hardware externally and MIDI seems to be the best way to do it. I'd like to keep this software as the author intended, without the bugs and maybe add a rich set of custom wave tables / instruments etc. Flash carts have an enormous amount of storage, might as well use some of it!
Yea it would be great to have song file management, but I dont see how you can possibly test midi without the proper gear. Maybe the forum can paypal you some money for a arduinoboy and midi knob controller?
In the meantime, id focus on fixing the other bugs, improving the wavetable quality etc.
Offline
herr_prof wrote:
It avoids them by minimizing realtime control
yes but midi sync and/or keyboard mode should be realtime
herr_prof wrote:
Maybe the forum can paypal you some money for a arduinoboy and midi knob controller?
BennVenn, if you would like to crowdfund an arduinoboy or you development, I would gladly give some $$ ;-)
Offline
Unsubscribe
cyberic wrote:
herr_prof wrote:It avoids them by minimizing realtime control
yes but midi sync and/or keyboard mode should be realtime
herr_prof wrote:Maybe the forum can paypal you some money for a arduinoboy and midi knob controller?
BennVenn, if you would like to crowdfund an arduinoboy or you development, I would gladly give some $$ ;-)
Midi clock data and note on/ofs are MUCH LESS data than someone tweaking a knob in realtime. I wouldnt be surprised if we are hitting a bottleneck on the gb serial port here, and it will need some sort of filter to cut down the bits we are bangin'.
Offline
herr_prof wrote:
Midi clock data and note on/ofs are MUCH LESS data than someone tweaking a knob in realtime. I wouldnt be surprised if we are hitting a bottleneck on the gb serial port here, and it will need some sort of filter to cut down the bits we are bangin'.
I see.
That's funny because this limitation was not present with the original hardware version.
So, a kind of threshold has to be applied, on arduino side, right?
Offline
Unsubscribe
well before (im guessing) is knob -> voltage - dac -> VALUES _> gameboy serial
now its knob -> voltage - dac -> VALUES _> MIDI SERIAL -> Arduino midi -> Gameboy Serial
So you have to figure out what furrtek did to scale the dac values and apply that to the midi serial data, and in a way that works with the MGB Code.
Offline
Actually I find the pot data not to be the issue. It is the internal clock of the Gameboy. Syncing to it seems to be the problem. I have flooded the midi stream to crushing levels with no real problems, it just comes down to finding a way to get a 'handshake' or some return bit from the Gameboy to keep them in time, as Ben has suggested. I have donated to Ben some cash and I would encourage those of you who are serious about this project and would like Ben to invest more time and resources to do so. Just PM him for his PayPal address.
Offline
Alabama
Pot data from actual pots tends to be very herky-jerky, and plagues some of my home-made MIDI controller projects. If you are having trouble with reading consistent values, try reading the value X many times, summing the values, then dividing by X to get an average. Adding in a comparison argument to automatically disregard reads greater or less than a certain amount of change will help. Basically, average read + discarding outliers = stable knob position reading. At least that works for me.
Offline
Unsubscribe
But you dont have to worry about reading pot data, cause the midi controller already does it for you! You just have to read the midi serial data, and update the software in a timely matter. The sync problem makes alot of sense based on what I am seeing, but I also think if you are blindly using the mgb modes to pass ccs, you are running into problems with cc 1 only has a 4bit value and is scaling for the setting. CC2 seems to work better which makes sense because it has at least 16 values to work with. Please someone correct me if Im wrong, i never used mGB.
Does the analog pots even work as we are describing on the real cart? Im guessing you dont get 127 discrete values for the filter res and cutoff there either.
Offline
Michigan
cyberic wrote:
herr_prof wrote:It avoids them by minimizing realtime control
yes but midi sync and/or keyboard mode should be realtime
herr_prof wrote:Maybe the forum can paypal you some money for a arduinoboy and midi knob controller?
BennVenn, if you would like to crowdfund an arduinoboy or you development, I would gladly give some $$ ;-)
I'm giving him an ARboy. So you can send me the money. Lol
Offline
Using my version of the Arduinoboy software, the version we added three pots to, the scaling for me seems the same for all three pots. I have not tried from an external controller yet, but I can soon. When triggering steady midi data the pot values change and are responsive to change. I have to flood the midi data with very fast arpegiations before I see a slow down of the actual values changing. Arduinoboy just passes the midi CC data right into the Gameboy and the rom itself interprets the data, so I don't think the resolution is an issue, but like I said I can try with an external controller and confirm this.
Offline
Unsubscribe
Can you try with just setting one tick of cc at a time? I dont have a controller with me but when I did that with cc automation, it responded very slowly, randomly.
Also what are you arduinoboy delay settings at? Mine are tweaked a lot to get lsdj midiout to work better.
Offline
herr_prof wrote:
Mine are tweaked a lot to get lsdj midiout to work better.
Is it tweaked to reduce the latency? Because I had a noticeable latency when I tried to use midi out
Offline
Australia
herr_prof wrote:
Midi clock data and note on/ofs are MUCH LESS data than someone tweaking a knob in realtime. I wouldnt be surprised if we are hitting a bottleneck on the gb serial port here, and it will need some sort of filter to cut down the bits we are bangin'.
DSC's arduinoboy code is pretty advanced in terms of digital filtering on the ADC inputs to prevent spurious MIDI CC's so the problem is not there, it would be the same effect from a midi controller. The issue as mentioned above is the data rate from knob tweaking in combination with no handshaking or error detection/correction. I'll find the refresh rate the original hardware used and limit the arduino code to that level. I know every iteration of the 'ReadPot' only read the value of one pot, changing every time it was called so I don't think the refresh rate on the original hardware was as fast as what could be achieved via MIDI.
The gameboy's serial port can sustain very high speeds. The bottle neck there is not the serial port but the speed the gameboy CPU can process the data. This has been tested in an experimental linker hardware where I can flash my flash cart in a very short time via the link port. 8mbytes transferred with zero errors in the bitstream. This makes me think the arduino is at fault. The serial stream is generated in software and perhaps an interrupt routine is not preserving registers at it should. In theory if the serial stream was out of sync, it would not get back into sync until 7 more errors occur in the bitstream and from the reports on here, it seems only 1 in a handful of MIDI commands are missed, supporting the theory that the error is generated in the arduino.
I have a MIDI keyboard/controller that I purchased for another MIDI project that I was working on so no need to crowdfund anything. I have an arduino in one of the many boxes I've packed (moving house) I just need to dig it out.
As for donations, DSC has been very generous in his contributions - not just via paypal but offering his own code he had developed and lessons learnt along the way. I am open to accept donations (Who doesn't like money!) but please understand that my real work takes me away from my computer (and often country) for weeks/months at a time. There are also unplanned commitments that I'm bound to at work and these take priority. I say this because I don't want to take anyone's money and not deliver. Any donations should be for the work that has been done or is in progress, not for promises etc... I hope you understand!
In other news, I've left my laptop, gameboy, flash cart, Joey Squinson and about 10 parcels I planned to post at my new house (3hrs drive away...) This really throws a spanner in the works. Wont be able to get down there till the weekend :-( I'll continue work via MGB and my GBC.
I'll try build the arduinoboy tonight, if the errors persist I'll re-write the code (arduino) from scratch in asm. You wont loose your bootloader so you can revert at any time and hopefully you'll loose all the bugs.
Offline
Unsubscribe
Sounds good, but ill probaly not use any forks of the aboy code (unless you left the other modes alone). Im not a Mgb use so dont really care about that. So youll be testing midi in and direct pot to arduino pin scanning at the same time? Perhaps it would be better to just make a separate product from arduinoboy if the low hanging fruit of piggybacking mgb support doesnt work out.
Back to the actual program: Can't for the life of me figure out how to edit a loop above 00. Anyone actually get a song going in this thing?
Last edited by herr_prof (Jul 12, 2015 1:24 am)
Offline
Australia
Well like I said earlier I cant smash out an entire program in Arduino like I can in Asm and even with the clean well written code of Arduinoboy there are still issues with latency and dropping bytes - mainly due to bitbanging the serial stream with interrupts enabled. Reports suggest this is not limited to mGB/303. Why not use the hardware SPI port!?!?!?!?!
Yes, testing MIDI in from my controller/keyboard as well as hardwired pots to the arduino.
Let me know if the loop 00+ issue is a code bug, I can at least work on that until I get my hardware together