So the Aeros has gone a long way from the time it was conceived, it is now a product and has a software team behind it. Before asking for more I need to acknowledge that the SingularSound guys have done an amazing job already. I do agree with David that the MIDI implementation has the highest priority now.
Please provide a MIDI command to directly load a specific song, like a PC. The Aeros could react to program change messages, just like BeatBuddy does. That would imply that the song order issue be fixed, so that we have useable IDs for the songs.
As I understand in the near future to load a song remotely one should send:
CC35-0 to go to the saved songs screen,
then send a number of CC36-0 to scroll to the wanted song (this number is a kind of ID for a song)
CC36-2 to select the song
CC35-1 to jump to the looper screen
I guess I will be able to program that into OnSong or Bandhelper, but a simple PC message like the BeatBuddy would be much easier to handle.
Or will there be another way?
Jared, that was a succinct way of stating what I was on about earlier. You basically create a MIDI implementation that covers all discrete functions of the device using a primitive command structure that allows for the most generic and open purpose. If the MIDI implementation tries to assume too much about how the device will get used (ie: gets fancy, internally implements toggle management, etc.), all that ends up happening is users get painted into a corner. A primitive and generic command structure can be used so many ways beyond the developers original intent. No developer can foresee, much less account for, all the ways users will want to set up their controllers.
If you are using mp3 backing tracks, one challenge with loopers is syncing the midi clock to them. Obviously you must have the tempo matched, but the problem comes matching the 1 on your track to the midi clock as it is often a few milliseconds off. My Infinity Looper has a āzero recordā feature, where the first loop recording basically resets the internal midi clock to match up with your mp3, so if the beat is 500 msec off, the midi clock gets shifted by that amount.
Iām running into an issue where the footswitches are too loud for me on activation (Iām working with a mic and a lot of gain). Seriously, they are twice as loud as a soft touch switch, and they are also resonant so they ring out. This makes the pedal basically unusable for me.
I donāt want to give up on the Aeros though. Midi implementation should include commands to mimic press and release of all 4 footswitches. This would allow me to use an external midi switch and avoid the built in switches. Rather than triggering specific commands (record new track, etc) they should trigger whatever a corresponding press on the built in switch would trigger, depending on context.
I would just like to have next song part on 6x6 move with the BB just like it does with 2x2.
Iād also like to see 2x4 that moves to the next part with BB.
Hands free song selection would be nice.
I second this. This is important for a ātoggleā midi control to maintain āstate consistencyā with midi controllers. If my midi controller is told to only to send a ā1ā when the button is pressed, the controller doesnāt know the resulting state of the device.
For example: My midi foot controller has lights on each pedal to indicate state. If I assign āmuteā to one of the buttons, then touch that button, the ā1ā signal is sent to the Aeros, mute state changes at the Aeros, and the light on the controller turns ON to indicate mute is activated. But then, a manual change to āun-muteā on the Aeros sets the midi controller permanently out of sync with the current state of the device until if/when the Aeros is manually toggled back. The light on the controller remains lit (which is okay), but when I click the button the controller assumes the device is switched to āun-muteā and the light goes out. The state consistency is lost.
Conversely (and usually), the midi toggle will act as described, sending a specific number (or range) for state. So, if my midi controller sends āmute,ā the Aeros is muted and the controller light turns on. If I manually un-mute the Aeros, the light on the controller stays on. But when I click the controller, the controller sends the āun-muteā signal, nothing happens at the Aeros (since it is already un-muted), and the light on the midi controller turns off like it should and state consistency is maintained.
Lacking this: How will the Midi Maestro handle the case when āmuteā is toggled on via Midi Maestro but Aeros is āun-mutedā manually? Will Midi Maestro be sent a signal by Aeros to indicate state change? If not, state consistency is lost when it shouldnāt be.