First thing to do would be to make sure you have a good SD card and good uncorrupted firmware and try to load it. Make sure to remove and reconnect the power after updating the firmware. If that fails, then the only other thing you can try on the software end of things is to reload the bootloader (it's unlikely that it's corrupt, but I'm not sure what the fuses are set to, so it's possible). To do this, you'll unfortunately need a separate programmer device for both the AVR side and the Cortex side (or send your chips back to Julian). So hopefully it's something simple like a bad sd card or firmware image.
I haven't messed with morphkits much in my travels through the firmware. I'll take a look at it once I'm done with the stuff I'm working on now though.I don't think it would be hard.
I have been playing with this great custom firmware, and I noticed the velocity in step edit doesn't work for the hihat channels. Anyone else notice this?
Well, I select one of the hihat channels while playing a pattern and go to step edit function. I select an active step and I see velocity, note and probability in the first page. The latter two function as they should, but no matter what velocity value I select, there is no change. On other voices/channels it works fine.
No it wouldn't be a hardware issue, it's all digitally produced sounds. Can you try a different voice patch for hats? It might be that your patch is set a certain way (like your drive is high so the velocity is not noticeable).
rudeog, your work on the MIDI interface is looking awesome! Is there any chance the mainboard could echo CC/NRPNs it receives from the front panel to the midi out/USB, so that patch editors can track their current values, please?
I've looked at this a little bit, and might play with it. My concern now is that you might get a storm of CC messages when a patch is loaded. But maybe that is desirable in the case of a patch editor?
Is there any way to use parameter automation to output midi CCs? Not sure if the midi transfer filtering in this firmware is applying to CCs generated by the LXR or coming through the midi in.
I think the CC storm should be fine, and indeed is desirable if you are controlling the LXR externally (and why else would you want to monitor those CCs if you weren't? weird choice to use the knobs as CC sends for other devices aside
@prontold, the midi filtering applies only to stuff generated by the LXR or received by the LXR (ie. not applied to midi thru data). Currently CC data lacks some implementation (it will receive CC, but not transmit CC).
@ceasless good point. I'm working on merging official firmware into custom firmware again (as @Julian added some fixes, and trigger code), and once that's done I might take a stab at this.
On the cortex side, each track is stored in memory. For each track, there are 16x8 notes, and for each note we store pitch, velocity, probability, 2 automation values, and 2 automation targets (byte each). Repeat that for 8 patterns. So that amounts to over 7 kilobytes for each track and 50 kilobytes for the whole lot. The chip has 192kb of RAM. I think right now we are using about 68k. So I think it could handle the extra data, and midi stuff is not very cpu intensive. Although I am not sure what @Julian's plans are for this RAM in other stuff in the future.
there may be some space left for additional patterns, but not much. You have to remember the RAM is not only used to store permament data, but is also used by the heap/stack. When I implemented the background loader for pattern sets, I first tried to load a complete pattern set (8 patterns ~50k) in the background, and the cortex could not handle it. It resulted in erratic behaviour, probably due to stack corruption.
Even 4 extra midi patterns would be very useful. Or a single pattern that allowed 4 note polyphony (3 extra notes to the main note as +/- semitone offsets)
Thanks rudeog! For your work and for the response.
Also thanks Julian. I just received and put together the LXR on Sunday and I have to say the instrument is great fun and the kit is probably the most well organized and user friendly DIY experience I've had. Enjoyed the weird German victory candy too (gum in poprocks???)!
I'm curious to know what MIDI messages the LXR can send besides note on, off, and number, but should probably look that up elsewhere.
@Dayflight, these two features are available in the custom firmware as "performance" (stores pattern, bpm and kit) and "all" (stores pattern, kit, bpm and all other settings)
Wondering if it might be possible to implement automatic pattern chaining for live recording. Could there be an option somewhere such that if you have record and play toggled in pattern mode, you can automatically record to the next pattern for a set number of patterns so that instead of composing one measure, then the next, then the next, you could play in a multi bar phrase that would automatically be looped as if it were a single pattern? Missing being able to play in 4-8 bars since I sold my Tempest.
Even 4 extra midi patterns would be very useful. Or a single pattern that allowed 4 note polyphony (3 extra notes to the main note as +/- semitone offsets)
@prontold If you set up the pattern chaining and start recording it will automatically record on the new pattern as it moves there. So eg you could chain all 8 patterns and record an 8 bar melody in one shot. To do this, go into perf mode, and then hold shift. Leave rpt at 0 and set next to the next pattern (so pattern 1 would be set to p2, pattern 2 to p3 ... pattern 8 to p1). That creates an 8 bar pattern.
Announcing new custom firmware. No major features at this point, I mainly wanted to get in sync with the new official firmware before I do anything new: - Merge against Sonic Potions 0.32 firmware to receive Sonic Potions changes and fixes - Track Length data is now saved with patterns, performances and "All" files* - track rotate will reset when sequencer is stopped
If anyone is using the trigger kit, note that I have not assembled my trigger kit yet, so have not been able to test the new stuff Julian did. I put the new trigger menu items under page 3 and 4 of the global menu (hold shift and hit menu 3 or 4 times to get to those pages). This differs (I think) from how Julian did it in the official FW.
*Please note that due to the way length data is handled, I chose not to preserve compatibility with length data in old versions. What this means is that you may still load old pattern files, but all tracks will have length 16 (the default). So if you have any old patterns that contain track lengths less than 16, note down these before upgrading and then edit them and save them again with the new firmware. Patterns saved in this new version should still be loadable by the official firmware, but all lengths will be 16. Basically what I've done is saved the length data for all tracks at the end of the full pattern chunk instead of interspersing it with the steps. It keeps the code a bit cleaner, and also allows the extra bits in the step data to be used for other future stuff without changing much code (or file format). If in doubt, back up your patterns before saving them in this new version.
Comments
Can you try a different voice patch for hats? It might be that your patch is set a certain way (like your drive is high so the velocity is not noticeable).
@ceasless good point. I'm working on merging official firmware into custom firmware again (as @Julian added some fixes, and trigger code), and once that's done I might take a stab at this.
You have to remember the RAM is not only used to store permament data, but is also used by the heap/stack.
When I implemented the background loader for pattern sets, I first tried to load a complete pattern set (8 patterns ~50k) in the background, and the cortex could not handle it. It resulted in erratic behaviour, probably due to stack corruption.
1. Automatic pattern - kit storage (a link between a pattern and its used kit)
2. Automatic storage of the initial setup like external sync (bpm = 0) and the set midi filter parameters
+1000 :-)) >:D<
To do this, go into perf mode, and then hold shift. Leave rpt at 0 and set next to the next pattern (so pattern 1 would be set to p2, pattern 2 to p3 ... pattern 8 to p1). That creates an 8 bar pattern.
- Merge against Sonic Potions 0.32 firmware to receive Sonic Potions changes and fixes
- Track Length data is now saved with patterns, performances and "All" files*
- track rotate will reset when sequencer is stopped
If anyone is using the trigger kit, note that I have not assembled my trigger kit yet, so have not been able to test the new stuff Julian did. I put the new trigger menu items under page 3 and 4 of the global menu (hold shift and hit menu 3 or 4 times to get to those pages). This differs (I think) from how Julian did it in the official FW.
*Please note that due to the way length data is handled, I chose not to preserve compatibility with length data in old versions. What this means is that you may still load old pattern files, but all tracks will have length 16 (the default). So if you have any old patterns that contain track lengths less than 16, note down these before upgrading and then edit them and save them again with the new firmware. Patterns saved in this new version should still be loadable by the official firmware, but all lengths will be 16.
Basically what I've done is saved the length data for all tracks at the end of the full pattern chunk instead of interspersing it with the steps. It keeps the code a bit cleaner, and also allows the extra bits in the step data to be used for other future stuff without changing much code (or file format).
If in doubt, back up your patterns before saving them in this new version.