Thanks for bringing that to my attention! I don't normally use the chaining so it's good to get some feedback on that. Can you check and make sure that it isn't a global option that is interfering? For normal pattern chaining (cueing) set 'pci' to off. Try also switching 'PC Reset' on or off. There's also an option to 'link' the viewed and playing patterns - make sure they are linked, as one of those will flash if they aren't and might be interfering with other flashing activitities.
Actually I don't think it flashes for the next cued pattern in the original firmware... I though it did but I looked in the wiki and there is no mention of this feature. I'd like it to not flash if the viewed and playing pattern aren't the same as I don't need that in performance mode.
More importantly, is there a chance you can fix the MIDI clock issue? (LXR doesn't properly play or pass through incoming MIDI events if there is MIDI clock signal coming in). Is Julian still working on the firmware?
first of all, I must really really say thanks a lot for your very nice work!
I really appreciate it a lot. The sequencer is already much more powerful and the LXR easier and more flexible to handle thanks to your work.
I'm soooo happy, you programmed proper program change (didn't try, yet. still figuring things out)
I have two questions:
1. when editing a pattern and then switching in perf mode to another pattern, the edit pattern stays active and I have to press SHIFT+PATTERN in order to be able to edit the next pattern. Makes sense, but confuses me a lot always.
For me it would be more logical to invert the led behavior of selected and active pattern
and is there a way that always the selected pattern in perf mode is the active edit pattern?
2. just for interest - there was the ability in perf mode to press one of the steps from 9-16 in order to shorten the overall pattern to 4/8 etc steps...
was this a firmware of another member or can you tell me what happened with these functions?
PS: I looooooove individual instrument selection! so glad it exists
hi youkon! glad it's working out for you! for (1) it sounds like you might have a global option switched. I think it's called 'sequencer follow' or something like that, that lets you choose whether the currently playing pattern is the one that is edited or not. Could be a bug, just try changing that and see if it corrects the problem.
(2) yeah, i agree those buttons in perf mode are a great place to add more functionality, just not sure what would be most appropriate. AFAIK, there has never been a function for those in the stock firmware or in mine. Some kind of looping function would be great.
I've gotta say, this is kinda on the backburner for me at the moment while I finish up my phd, but the LXR is still something I work with a lot - things will keep coming, just slowly.
Good to know that myself! I don't do a whole lot of MIDI Out from the LXR
I'm working on adding a few little things over the weekend. More improvements to roll, I'd like to have kits wait to load the same way pattern does when perf/all is changed. some other minor tweaks to the UI.
Lots of other things I'd love to add, and I'd like to try ironing out that pattern chain bug. just down to the time i can put in...
Hello Brende(andclarke ;-)) I have downloaded your GITHUB souce code about 037 dev version where you load individuel tracks :-) I am very interested in integrating this LOAD/SAVE feature to my LWR-OWL program.
I did merge your code to mine... and the load/save works but all the sounds are strange !!!
I don't know how I could find where comes from the error -:-(
I was wondering if you could help me ? could you integrate into my LXR-OWL version your LOAD/SAVE kits for me ? or give me some explanations to be able to integrate them without errors ? (As I said I have merge your code but I got stange sounds :-( ).
Hello Brende(andclarke ;-)) I have downloaded your GITHUB souce code about 037 dev version where you load individuel tracks :-) I am very interested in integrating this LOAD/SAVE feature to my LWR-OWL program.
I did merge your code to mine... and the load/save works but all the sounds are strange !!!
I don't know how I could find where comes from the error -:-(
I was wondering if you could help me ? could you integrate into my LXR-OWL version your LOAD/SAVE kits for me ? or give me some explanations to be able to integrate them without errors ? (As I said I have merge your code but I got stange sounds :-( ).
Thanks!
Not sure I have time to learn another firmware branch, but usually when things seem to be working ok, but kits don't sound right, it means there's a parameter mis-alignment. In the AVR (front-board) code, 'presetManager.c' has arrays for identifying the parameter numbers for each voice. Make sure these line up with the actual parameters from 'Parameters.h'.
There is also an offset of 1 between the parameter numbers the AVR uses and the ones the STM (mainboard) uses. I can't remember off the top of my head which way that breaks. I think the first param on the AVR is 1 and the first on the STM is 0, maybe check that's not causing your problems.
- Voice audition. When in 'voice' mode with the sequencer stopped, the currently selected sound can be auditioned by pressing its voice select button again. Also useful when in the voice load menu.
- Load 'perf/all' change - When loading a 'Performance' or 'All' file while the sequencer is running, the Drumkit will wait to change until a pattern is selected, to be consistent with the behaviour of the pattern data.
- Kit Reset - Sending MIDI Program Change to global channel with value 8-15 will change to the corresponding pattern (PC# modulo 8, normal behaviour for PC 0-7) but ALSO force the drumkit to reset to the last kit loaded (whether from a 'drumkit' file, 'performance' file, or 'all' file). The idea is that you can manually adjust sound parameters and then immediately recall the kit on command.
- Improved roll - roll successfully uses the sequencer quantize setting. the shift-record button menu now has a "roll mode" option instead of note lock. the options are as follows: -trig: when a roll is active, it uses note and velocity data from the sequencer, and ignores the perf menu roll options -note: the roll will only trigger if the current sequencer step is active. note derived from the perf menu roll note, velocity from sequencer data -vel: the roll will only trigger if the current sequencer step is active. velocity derived from the perf menu roll velocity, note from sequencer data -both: the roll will only trigger if the current sequencer step is active. velocity and note derived from the perf menu roll options -all: 'normal' roll mode - the roll will always trig, and use the values from the perf menu roll options
All the roll modes will be recorded to the sequencer as they are heard when record is active. The 'note' and 'vel' can be particularly useful for overdubbing notes and velocity into previously recorded staps.
Have fun! I'll try to get an individual voice morph (for sequencer automation and MIDI CC) this week.
This is a fun one, but with great power comes great responsibility...
Individual voice morph - morphs only a single voice instead of the whole kit. This is available 3 places for now: - You can assign it to a performance macro (so it will be available on the same page as kit morph) - You can set it as an automation parameter on a sequencer step (great with pattern changes and probability!) - You can set it as a mod destination (ie assign an LFO). This is a bit dangerous, do not assign too many LFOs to voice morph. I've limited voice morph to only updating at every 32nd note to keep the MIDI bus from being completely saturated, but assigning all the LFOs to morph can slow down the menu interface, lead to dropped messages, or possibly crash it (I've tried to crash the LXR by doing this and I haven't been able to, but I'm sure it can be done). - I will add MIDI mod wheel (CC1) on the voice channels as another way of controlling it shortly. This replaces the 'load from kit' automation I had in before, which was honestly a pain in the ass to use properly and tended to crash things quickly. This is a way more awesome-er addition
crazy glitchy modulation sounds pretty good too I'd love to get it higher, but the issue is every morph means 37 parameter MIDI messages have to go from the AVR to the cortex. about 16 32nd notes a second is about 600 messages a second just for one LFO... and the MIDI bus has about a 1200 msg/sec bandwidth so... yeah, I might slow that down more at some point but I'm willing to see how much I can push it
More new stuff! - Shift-Play re-loads the last loaded drum kit parameters.
- Individual Track Pattern Changes - when in PERF mode, hold one (or more) voice buttons. Then press a select button, as you would for changing patterns. Only those voices of the held buttons will switch to the new pattern. There is no visual feedback for this.
Voice mutes in PERF have been moved to voice button RELEASE (and they won't be muted if a pattern change is detected). Individual pattern changes can also be performed by sending a PROGRAM CHANGE MIDI message with a value 0-7 on an individual voice's MIDI channel.
And - one more. Looper. In PERF mode, sequencer buttons 9-16 let you repeat the currently playing section of the sequence. button 10 repeats an interval of 64 sub-steps (1/2 bar), button 16 repeats a single sub-step (128th note). The in-between buttons repeat 1/4, 1/8, 1/16, 1/32, and 1/64 intervals respectively. Button 9 will "dot" the loop interval (increase by half). The loop start is quantized based on the shift-record menu. The loop can be overdubbed onto the current sequence by enabling record.
that should be a fun one for over the weekend gonna take another break now, let some more bugs shake out and then maybe think about fixing some of the longstanding issues on my list. I'm finding it hard to think of more things I want these days. I'd love to add pwm and proper looping samples some day, but I need to spend a lot of time with the DSP code to even attempt those!
@-) ; Damn, I've only had mine a short while and still haven't completely got to grips with the stock firmware, but I may need to load this up this weekend!
@-) ; Damn, I've only had mine a short while and still haven't completely got to grips with the stock firmware, but I may need to load this up this weekend!
Good Luck! It should largely work as described in the manual for the stock firmware, the most obvious exception being the expanded multipage PERF menu. Other than that, I've tried to add functionality, rather than replace.
Also, I will try to start putting up a series of videos on the new features this weekend, I know some of them can be um... esoteric
Thanks a lot Brendan for the huge amount of work you are putting into this ! :-bd
I'm really looking forward to seeing your videos because I've been reluctant to trying your firmware so far due to the lack of documentation of the new features...
I have been playing for few months with your custom firmware, one of the early version with kit and individual voices load option. It is a great tool for my live formation.
I just uploaded today the new version of the Firmware and I must say, I am really impressed. So much more sequencing options, it is a new dimension, the LXR was an amazing machine, it is now a beast!
Thanks a lot for your work!
I have nevertheless stumbled upon some trouble with my use of the LXR. Especially with rolls.
i use rolls a lot with my live formation, where we all improvise during at least two hours. The way the stock firmware was working for quantizing and triggering rolls was perfect for that: no matter when you pressed the roll button, it would start on a main step (and not on a substep) and will always be quantized.
you have implemented new features for the quantization of rolls and they are great.
But I am not sure that the way it works now is the best. When you press a roll button, the few first notes will be out of time and then be quantized. this is a problem if, like me, you like to record small rolls and not continuous ones. When recorded, these small rolls are perfectly on times, but when played and auditioned they are not heard at all the same.
I also noticed that when you press more than one roll button at the same time (to roll different instruments), odd timing occures. For an example, I press the HH roll button, it starts to roll on a substep, thus not quantized, then it catches on with the set quantization. But if I press simultaneously another roll button, let's say the drum2 roll, the later instrument roll will be out of time. It is the same way around; if you do a Drum2 roll and simultaneously a HH roll, the HH will not be heard and auditioned quantized.
Is this a bug or a decided feature? Did I miss something?
These of course are my personal thoughts about using the LXR live, it would be great to have the option to keep the old roll quantization/behaviour with your new note+velocity options.
I'm really excited about using all your new features, but these problems are keeping me from using your firmware live. I have one Gig alongside Legowelt coming soon and would love to get wild with your amazing firmware.
Yup! This was a bug. Thanks for that! I think I have a fix. I'm working on some menu improvements too at the moment, I'll post an update before I go to bed tonight.
Note that there are a couple things going on here. There is an issue with the firmware posted now with rolls maintaining time. This is separate from a slight delay between the "first few" rolls that can be heard occasionally when quantize is switched on. What happens is this: If you have quantize on, and you start a roll on a non-quantize step, the sequencer has to decide what to do. If the sequencer always waits until the next quantize step, and the user has a coarse roll rate and a coarse quantize, the roll won't come it where it is expected about half the time.
To compensate for this, what I have it doing is that if the roll comes in closer to the next quantize step than the last one, the sequencer waits to turn on the roll. If it comes in earlier, the sequencer assumes you wanted to start the roll on the LAST quantize step and triggers the sound immediately, but waits the appropriate amount of time until triggering the next instance of the roll. All the roll sounds after the first then trigger exactly where they should be. However, because our ears are very sensitive to the duration of time between transients, if the first roll is triggered late, the second roll will sound "early", even though it is exactly on grid, making it sound like the sequencer is playing 'catch-up'. To avoid the 'catch-up' sound, it might be best to turn off quantize.
I can also play with where in the quantize division the sequencer decides to go early or late - like maybe doing 25% early 75% wait until next quantize division. I'm a bit reluctant to do that - there's no clear place other than 50% that isn't down to personal taste. The other thing I can think of is to make "force sequencer to delay roll onset to next quantize division" a global option. It would be kinda an esoteric option.
This was never an issue in the old firmware because rolls were always quantized, since they were calculated as a pattern relative to the whole bar, that always started on the first step of that bar. That is not what a roll is. This made the implementation extremely limited in that you couldn't have two rolls going at the same time that didn't overlap, or have off-beat rolls continue their polyrhythms past a single bar.
The new method is much more tricky, code-wise, but a great deal more useful (once any more bugs are out!). I won't be going back to the old implementation, but I will keep working to make sure it can do everything the old one did, and more. It's a feature I use a lot, too.
Check the new version when I put it up - I think it's a lot better now, and let me know if there's anything else that could go in there!
Comments
Hi brendanclarke!
first of all, I must really really say thanks a lot for your very nice work!
I really appreciate it a lot. The sequencer is already much more powerful and the LXR easier and more flexible to handle thanks to your work.
I'm soooo happy, you programmed proper program change (didn't try, yet. still figuring things out)
I have two questions:
1. when editing a pattern and then switching in perf mode to another pattern, the edit pattern stays active and I have to press SHIFT+PATTERN in order to be able to edit the next pattern. Makes sense, but confuses me a lot always.
For me it would be more logical to invert the led behavior of selected and active pattern
and is there a way that always the selected pattern in perf mode is the active edit pattern?
2. just for interest - there was the ability in perf mode to press one of the steps from 9-16 in order to shorten the overall pattern to 4/8 etc steps...
was this a firmware of another member or can you tell me what happened with these functions?
PS: I looooooove individual instrument selection! so glad it exists
keep on going the great work
cheers, youkon
(2) yeah, i agree those buttons in perf mode are a great place to add more functionality, just not sure what would be most appropriate. AFAIK, there has never been a function for those in the stock firmware or in mine. Some kind of looping function would be great.
I've gotta say, this is kinda on the backburner for me at the moment while I finish up my phd, but the LXR is still something I work with a lot - things will keep coming, just slowly.
thanks brendanclarke!
it was as you said sequencer follow
question: are the mute buttons of the instruments midi mutes as well (mute the outgoing midi)?
and: does each instrument send its midi data out on their own midi channel?
(I did set up my LXR to: Global channel 1, drum1 channel 2, drum2 channel 3, drum3 channel 4, snare channel 5 and so on, note to ANY)
I think, I answered my questions myself with both yes
(just having some midi trouble during recording from lxr to cirklon and backwards)
I'm working on adding a few little things over the weekend. More improvements to roll, I'd like to have kits wait to load the same way pattern does when perf/all is changed. some other minor tweaks to the UI.
Lots of other things I'd love to add, and I'd like to try ironing out that pattern chain bug. just down to the time i can put in...
I have downloaded your GITHUB souce code about 037 dev version where you load individuel tracks :-)
I am very interested in integrating this LOAD/SAVE feature to my LWR-OWL program.
I did merge your code to mine... and the load/save works but all the sounds are strange !!!
I don't know how I could find where comes from the error -:-(
I was wondering if you could help me ? could you integrate into my LXR-OWL version your LOAD/SAVE kits for me ? or give me some explanations to be able to integrate them without errors ? (As I said I have merge your code but I got stange sounds :-( ).
Thanks!
There is also an offset of 1 between the parameter numbers the AVR uses and the ones the STM (mainboard) uses. I can't remember off the top of my head which way that breaks. I think the first param on the AVR is 1 and the first on the STM is 0, maybe check that's not causing your problems.
Good Luck!
- Voice audition. When in 'voice' mode with the sequencer stopped, the currently selected sound can be auditioned by pressing its voice select button again. Also useful when in the voice load menu.
- Load 'perf/all' change - When loading a 'Performance' or 'All' file while the sequencer
is running, the Drumkit will wait to change until a pattern is selected,
to be consistent with the behaviour of the pattern data.
- Kit Reset - Sending MIDI Program Change to global channel with value 8-15 will change to the corresponding pattern (PC# modulo 8, normal behaviour for PC 0-7) but ALSO force the drumkit to reset to the last kit loaded (whether from a 'drumkit' file, 'performance' file, or 'all' file). The idea is that you can manually adjust sound parameters and then immediately recall the kit on command.
- Improved roll - roll successfully uses the sequencer quantize setting. the shift-record button menu now has a "roll mode" option instead of note lock. the options are as follows:
-trig: when a roll is active, it uses note and velocity data from the sequencer, and ignores the perf menu roll options
-note: the roll will only trigger if the current sequencer step is active. note derived from the perf menu roll note, velocity from sequencer data
-vel: the roll will only trigger if the current sequencer step is active. velocity derived from the perf menu roll velocity, note from sequencer data
-both: the roll will only trigger if the current sequencer step is active. velocity and note derived from the perf menu roll options
-all: 'normal' roll mode - the roll will always trig, and use the values from the perf menu roll options
All the roll modes will be recorded to the sequencer as they are heard when record is active. The 'note' and 'vel' can be particularly useful for overdubbing notes and velocity into previously recorded staps.
Have fun! I'll try to get an individual voice morph (for sequencer automation and MIDI CC) this week.
I noticed that the potential lfo bugs are present. Here's how to reproduce, if you want to give it a go:
http://forum.sonic-potions.com/discussion/825/weird-sound-problem-with-lxr#Item_2
Individual voice morph - morphs only a single voice instead of the whole kit. This is available 3 places for now:
- You can assign it to a performance macro (so it will be available on the same page as kit morph)
- You can set it as an automation parameter on a sequencer step (great with pattern changes and probability!)
- You can set it as a mod destination (ie assign an LFO). This is a bit dangerous, do not assign too many LFOs to voice morph. I've limited voice morph to only updating at every 32nd note to keep the MIDI bus from being completely saturated, but assigning all the LFOs to morph can slow down the menu interface, lead to dropped messages, or possibly crash it (I've tried to crash the LXR by doing this and I haven't been able to, but I'm sure it can be done).
- I will add MIDI mod wheel (CC1) on the voice channels as another way of controlling it shortly.
This replaces the 'load from kit' automation I had in before, which was honestly a pain in the ass to use properly and tended to crash things quickly. This is a way more awesome-er addition
- Shift-Play re-loads the last loaded drum kit parameters.
- Individual Track Pattern Changes - when in PERF mode, hold one (or more) voice buttons. Then press a select button, as you would for changing patterns. Only those voices of the held buttons will switch to the new pattern. There is no visual feedback for this.
Voice mutes in PERF have been moved to voice button RELEASE (and they won't be muted if a pattern change is detected). Individual pattern changes can also be performed by sending a PROGRAM CHANGE MIDI message with a value 0-7 on an individual voice's MIDI channel.
One of my fave things on mono machine was to screw up the sounds and then retrigger the sound to be loaded back to normal.
You could mess up all of the same parameter on all sounds , then reload ..great with fx / eq / release times.
:-\"
Always thankful for your efforts!
Looper. In PERF mode, sequencer buttons 9-16 let you repeat the currently playing section of the sequence. button 10 repeats an interval of 64 sub-steps (1/2 bar), button 16 repeats a single sub-step (128th note). The in-between buttons repeat 1/4, 1/8, 1/16, 1/32, and 1/64 intervals respectively. Button 9 will "dot" the loop interval (increase by half). The loop start is quantized based on the shift-record menu. The loop can be overdubbed onto the current sequence by enabling record.
that should be a fun one for over the weekend
Have fun!
Also, I will try to start putting up a series of videos on the new features this weekend, I know some of them can be um... esoteric
I'm really looking forward to seeing your videos because I've been reluctant to trying your firmware so far due to the lack of documentation of the new features...
Note that there are a couple things going on here. There is an issue with the firmware posted now with rolls maintaining time. This is separate from a slight delay between the "first few" rolls that can be heard occasionally when quantize is switched on. What happens is this: If you have quantize on, and you start a roll on a non-quantize step, the sequencer has to decide what to do. If the sequencer always waits until the next quantize step, and the user has a coarse roll rate and a coarse quantize, the roll won't come it where it is expected about half the time.
To compensate for this, what I have it doing is that if the roll comes in closer to the next quantize step than the last one, the sequencer waits to turn on the roll. If it comes in earlier, the sequencer assumes you wanted to start the roll on the LAST quantize step and triggers the sound immediately, but waits the appropriate amount of time until triggering the next instance of the roll. All the roll sounds after the first then trigger exactly where they should be. However, because our ears are very sensitive to the duration of time between transients, if the first roll is triggered late, the second roll will sound "early", even though it is exactly on grid, making it sound like the sequencer is playing 'catch-up'. To avoid the 'catch-up' sound, it might be best to turn off quantize.
I can also play with where in the quantize division the sequencer decides to go early or late - like maybe doing 25% early 75% wait until next quantize division. I'm a bit reluctant to do that - there's no clear place other than 50% that isn't down to personal taste. The other thing I can think of is to make "force sequencer to delay roll onset to next quantize division" a global option. It would be kinda an esoteric option.
This was never an issue in the old firmware because rolls were always quantized, since they were calculated as a pattern relative to the whole bar, that always started on the first step of that bar. That is not what a roll is. This made the implementation extremely limited in that you couldn't have two rolls going at the same time that didn't overlap, or have off-beat rolls continue their polyrhythms past a single bar.
The new method is much more tricky, code-wise, but a great deal more useful (once any more bugs are out!). I won't be going back to the old implementation, but I will keep working to make sure it can do everything the old one did, and more. It's a feature I use a lot, too.
Check the new version when I put it up - I think it's a lot better now, and let me know if there's anything else that could go in there!
Thanks!