Sigh. This shield is pretty cool. The example code is a bit thin. So, here's a sketch that plays a bunch of random notes, as it steps through the different sounds the fluxamasynth can play.
Okidoke. Will do. I've been trying to get the software serial theory into practice, without any luck. Just looking at the Fluxamasynth.cpp file, I can see that it's calling "Serial" for all of its commands. Is that going to be hard coded to the hardware serial device? I don't know much about how this works, but if I wanted to use a different serial device, like the software serial device, wouldn't I need to pass a reference for which serial device to make the function calls to?
Maybe when the fluxamasynth object is being created, pass in which serial device I want it to work with? Just stabbing at science here. I barely speak english, and zero c++... so feel free to edify me. Please edify me, I mean.
Ok, right, so... software serial doesn't have a "write" function, so that's not going to work as-is. I can see that softwareserial has a print function, and seemingly with a BIN converter, but ... I don't know how to handle the buffer length parameter with software serial. Any clues?
Am I on the right track here? I can see the buffer length matches the string of commands lined up, so if I break each of the commands into its own mySerial.print(command1,BIN); does that get me to functional parity as what the hardware serial is doing? Here's the first few lines of the fluxamasynth.cpp file converted with my "stabbing at science" method. I'm posting it up here so hopefully you can stop me or correct me before I go through and change the rest of the file... if I'm wrong, I don't want to spend a lot of time on being wrong. So.. I'll wait to hear back before proceeding further.
What you are doing with software serial will certainly work, but it's a bit of coding though. The right place to do this is in the library and we're currently merging in some customer code that does this (uses software serial) Check the wiki in a week or so.