65

(10 replies, posted in Software & Plug-ins)

Vellain wrote:

@Trash80: I like how your name is on one of the color themes... pretty chill

It's what happens when you pick some colors and someone likes them enough to include them. wink

ashimoke wrote:

I think it should work - the official nintendo cables / adapters have all the pins present afaik.

No, most if not all cables including official ones are missing power. I think their rule of thumb was: If the connecting device is not a another gameboy and needs 5v power, use the pin- Such as any light unit or the 4 player adapter. You can of course hack a cable, heres a photo set tutorial I made for the DMG 04: http://www.flickr.com/photos/trash80/se … 324137185/

67

(10 replies, posted in Software & Plug-ins)

Here I have one.
http://trash80.com/junkfood/NESNOISE.xrni.zip

Dont know too much about Wiring except much of the Arduino platform used it originally- Don't even know how much it's strayed from that now. I know , well at least I think I know Serial is actually C++, and I would guess thats true with EEPROM, not so sure about the I/O, it's been quite awhile since I've looked at the source. Either way C++/C it's all good stuff. wink

69

(47 replies, posted in General Discussion)

low-end theory? That the theory about the mystical brown-note or is it like some sort of dubstep thing?

Note: Arduinoboy is actually all C except for some of the libraries it uses (top of my head: Serial, digitalRead/Write, EEPROM)- which could be rewritten pretty easily to use existing C/++ libs out there. What exactly are you using? Some port of Arduino/Wiring code?

Back on topic, I'd suggest using something like what Oliver did with Nanoloop by using a PCB for the Gameboy gamelink plug, that seems to be a cheap & clean way of dealing with the nonstandard game link jack without sacrificing cables or Gameboys in the process.

Glad to hear about the project! Sounds like fun. smile

Auxcide wrote:

C is for Cookie

Haha!

It's called sarcastic dark humor guys. If you don't get it, well, where have you been these last 2 years?

Also "The only thing that ended was this genre" is way more funny than "I like cookies"

lastfuture wrote:
ant1 wrote:

"You can't simply send notes or pattern effects etc. to LSDJ and expect it to know what to do with them. That means you won't be able to control, say, instruments you set up in LSDJ with Renoise."

isn't this possible (sort of) with the lsdj keyboard interface?

Good point. It would be an entirely manual process though (unless I'm terribly mistaken) ... unless somebody is crazy enough to build something that takes MIDI in and converts it to qwerty button presses through a PS/2 cable. That would be sick.

edit: Arduinoboy can't do that can it? Just making sure

Arduinoboy supports LSDJ keyboard mode if that's your question.
There is also a special version of LSDJ that adds MIDI out, or MIDI note to LSDJ row# trigger, which should work pretty amazingly well in renoise- you have to match the BPM in renoise and LSDJ as it don't receive sync clock due to the architecture- but it should stay in sync as long as the BPMs are the same.

lastfuture wrote:

It's quite alright. Just find it fascinating that the entire lower half pitch bend goes weird the second the note is a semi tone "too low" especially since the bend would theoretically go through all the same pitches as the one above it except one semi tone at the very bottom of the range.
I don't find this fatal at all, I just don't understand how it happens. I agree that it adds some interesting glitch potential, especially when using it on notes well outside the range below C-3 smile

It's most likely because the math exceeds a 16 bit number, thus wrapping the bits and causing the glitch.

Yeah as I said before there is no "if" condition to lower bound pitches. Adding it just adds overhead that is easy to avoid. Also it can be seen as a feature for glitchy effects. wink The large pb range wrap around is probably because it exceeds the 16bit unsigned int, I don't want to move it to a 32 bit, again because of overhead. I think its a fair trade off with the increased resolution.

Okay updated to 1.3.3 ... Let me know how it goes.

http://code.google.com/p/arduinoboy

Oh wait I see... let me look.

It's not the math, you are hitting the lowest note possible and it's wrapping. I could put in a if condition to avoid the wrapping, but that adds overhead. Every instruction counts to keep up with MIDI data on a DMG.

fluxer wrote:

What is your current math, out of curiosity?

The shifting is to give some precision to avoid floating point math...

if(pbWheelIn[synth] & 0x80) {
    currentFreq = freq[noteStatus[synth_pitch]] + (((freq[pbNoteRange[synth_note_range+1]] - freq[noteStatus[synth_pitch]]) * (((pbWheelIn[synth] - 0x79)<<7) / 0x80))>>7);
} else {
    currentFreq = freq[noteStatus[synth_pitch]] - (((freq[noteStatus[synth_pitch]] - freq[pbNoteRange[synth_note_range]]) * (((0x80 - pbWheelIn[synth])<<7) / 0x80))>>7);
}

I changed it to +-7 bit precision. Check it out now: (v1.3.2)
http://code.google.com/p/arduinoboy/

And I'll optimize this later and rewrite it in asm. Don't have time lately.

fluxer wrote:

Thank you Trash80! I will most likely try it out tomorrow.

The 32-step pitch bend is apparent even on low to mid range notes. Is the NanoUSB at fault here then? Is it only sending mGB a 5-bit pitchbend signal?

Can anyone with an Arduinoboy confirm that mGB will interpret higher-res pitch-bend messages sent from one?

It may well be 32 steps at the fault of my math. (I do some shifting for precession since there are no floats) It's tricky to get the little guy working properly with as few instructions as possible. Maybe I'll rewrite it at a later time to use some sort of scaled lookup or something else.