Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Release Candidate Firmware V3.01 RC1
#1
There is another release candidate which adds some nice and long requested features as well as many fixes, improvements and stuff you never asked for :-)

Please, if you find some time, test it and let me know if things are running well (or not). As usual more people testing, more response, faster stable release. 

Check here what's new:
Audio
- added loop, pinpong and frame + loop/pingpong functionality for samples.
- added mapping destinations for samples (AUDI SP0-11  START/END/POS) to change the start, end or both
- added resampling screens for the samples so if a sample is too long (or manually by loading the sample with SHIFT+OK) a lower samplerate can be selected
- loading samples in a lower samplerate can be selected with or without interpolation
- added 24 and 32bit PCM sample support
- added Kill command for samples
- added play sample X on audio channel Y for I2C/Multi tracks drummatrix
- added sample OSC mode. If a sample is set to one of the loop options then it can either act like an oscillator (keeps looping) or stops when a track is stopped.

Envelopes
- added additional exponential envelope responses (experimental, choose LIN/EXP with envelopetype. Might affect the performance!! Is mostly fine.)
- updated retrigger behaviour with ADSR envelopes so they are more equal to a typical analogue functionality

Mapping
- fixed mapping 'add pending table ticks' will work also now with XMAP
- added mapping table destinations to fire/restart and stop tables on tracks
- Added new mapping XMAP source command: XSHT is a 1 shot multi row XMAP depending on the raising state of the former row
- Added new mapping XMAP 1Shot destination commands: Multi row XMAP depending on the raising, falling or on change of the source

General
- added a basic Scope (Setup->NerdScope) with 1 trigger (no trig, raising, falling, changing edge) and 4 channels. The input/trigger values are received though the new mapping destinations Global -> SCTV (for the trigger input), SCP1-4 (for the channel input). The 'timebase', enabled channels, trigger level and type can be changed in the scope screen.
- fixed sequencer screen possible glitches on lowest rows (EF-FE)
- added 'delete projectfile' which moves a projectfile to the backup folder
- fixed stop of midi notes when entering the midi pattern screen via OK
- fixed patch editing for Multi/I2C FX. Fixed create patches, added regular patch editing for I2C tracks
- fixed 'CBPB clock now 1xx' problem which caused an 'out of sync' if switching to dividers
- fixed issue that a new clock or patternorder would be activated already when pressing START to cue something instead of with the upcoming pattern
- fixed local trigger indicator in video pattern
- replaced unused Track 'pattern start position' mapping destination with 'Fire Patch' (TRCK TRKx PTCH) destination. Patch defined by former row
- fixed table editing for the transpose column
- fixed inconsistency with the sequencer screen use of the last edited pattern
- fixed pattern screen update if euclidean is being changed (showed accidentally on the Launchpad)
- added colours will now also be copied/pasted on the sequencer screen
- added workaround for the case if a midi master wrongly sends the same note twice.
- added VEX connected PC Keyboard to Midi routing which adds the full support of the midi in functions but then for the PC Keyboard (including polyphony, recording etc) (Setting in the Midi/I2C setup screen. PC Keyboard > Midi Input Port/Channel X and in the general routing you use port/channel x then to be used as track record etc just like it is a midi device).
- fixed missing note off/gate off issue with dualchord on pattern stop
- changed default for midi tables to 'no retrig' for all 16 rows
- fixed table bug where tables using >>> and zero selected allowed notes would cause an endless loop = freeez
- fixed possible wrong finetune scaling if 'avoid' was selected for local cv/gate
- updated many copy+paste parts for patterns which adds more 'compatible to each other' fields
- fixed 'set dualchord trigger' command
- fixed dualchord trigger to 'other' destinations than the dualchord itself
- fixed user interface import/export which didn't save the 'Window Lines' colour properly

As usual, this is a release candidate. It is not intended for productive use as I can't guarantee that they are no unexpected side effects. Also saved projects will guaranteed work for the release version but are not backwards compatible to 3.00 or earlier. So be aware to backup your projects / SD Card first!!! (Which is something you should do anyways from time to time)
But with installing it and trying it out/testing you help getting the version ready for stable use. I aim as usual to release as soon as possible.

Please report any issues with that only in this thread here as this is not a stable version. 

Download the release candidate below, follow the firmware update rules and if you get stuck there and it doesn't work, read the many threads about it and it will be fine!! Updating the NerdSEQ always works!


.hex   nerdseq.hex (Size: 5,48 MB / Downloads: 90)

.zip   nerdseq.zip (Size: 1,72 MB / Downloads: 57)
PLEASE use the search function if something have been asked or discussed before.
Every (unnessesary) forum support means less time to develop! But of course, i am here to help!  Smile
Reply
#2
Another large update! There are some great quality of life improvements in there.. in particular the sample functions, colour copying for patterns and exponential envelopes! Great work, will look forward to checking this out.
Reply
#3
Very cool! PC Keyboard to MIDI routing!
With looping audio samples and position modulation, wavetable like changes should now be possible!
Also great is the inbuilt audio conversion, so preparation of samples will be a lot easier!
A big thank you!
Reply
#4
Awesome news!!!
Reply
#5
Hello!

I tested this briefly, just playing back a small project experiment. I experienced a different behaviour to that of v2.01a - and of v3.0. These two versions play it back in equal fashion, so I should hope this concerns v3.01rc1.

The issue:
There's a simple table - only one line with a RND command (tranpsose column), then a hop back to 00 on the next line.
I have cloned it so to have three tables for some variation - just changing the allowed notes (and range). All are set to COIN quanization and locked to the same scale.

Upon playback, v3.01rc1 does stick to the allowed notes, but it "chooses"/plays other notes than 2.01a/3.0. On two occations out of four tests (turning my system on and off in between), it chose even other notes.. so it played two variations, one could say. Versions 2.01a/3.0 plays the same exact notes every time (well, I haven't used v3.0 until tonight, but it seems to do act like 2.01a in this regard)

In the end, I'm left to wonder if this behaviour is the new norm? Perhaps it's what the note "- fixed table editing for the transpose column" alluded to? Or is it an unforeseen effect in this release candidate?

Greetings from Norway
Reply
#6
(02-14-2026, 03:04 AM)tepjz Wrote: Hello!

I tested this briefly, just playing back a small project experiment. I experienced a different behaviour to that of v2.01a - and of v3.0. These two versions play it back in equal fashion, so I should hope this concerns v3.01rc1.

The issue:
There's a simple table - only one line with a RND command (tranpsose column), then a hop back to 00 on the next line.
I have cloned it so to have three tables for some variation - just changing the allowed notes (and range). All are set to COIN quanization and locked to the same scale.

Upon playback, v3.01rc1 does stick to the allowed notes, but it "chooses"/plays other notes than 2.01a/3.0. On two occations out of four tests (turning my system on and off in between), it chose even other notes.. so it played two variations, one could say. Versions 2.01a/3.0 plays the same exact notes every time (well, I haven't used v3.0 until tonight, but it seems to do act like 2.01a in this regard)

In the end, I'm left to wonder if this behaviour is the new norm? Perhaps it's what the note "- fixed table editing for the transpose column" alluded to? Or is it an unforeseen effect in this release candidate?

Greetings from Norway

Hey thanks. The fixed transpose column was purely an editing thing.
Can you maybe provide me a 2.01/3.0 project so I can see what you mean and compare these myself?
I am not aware about any change in the randomization but you never know..
PLEASE use the search function if something have been asked or discussed before.
Every (unnessesary) forum support means less time to develop! But of course, i am here to help!  Smile
Reply
#7
(02-14-2026, 08:03 AM)XORadmin Wrote:
(02-14-2026, 03:04 AM)tepjz Wrote: Hello!

I tested this briefly, just playing back a small project experiment. I experienced a different behaviour to that of v2.01a - and of v3.0. These two versions play it back in equal fashion, so I should hope this concerns v3.01rc1.

The issue:
There's a simple table - only one line with a RND command (tranpsose column), then a hop back to 00 on the next line.
I have cloned it so to have three tables for some variation - just changing the allowed notes (and range). All are set to COIN quanization and locked to the same scale.

Upon playback, v3.01rc1 does stick to the allowed notes, but it "chooses"/plays other notes than 2.01a/3.0. On two occations out of four tests (turning my system on and off in between), it chose even other notes.. so it played two variations, one could say. Versions 2.01a/3.0 plays the same exact notes every time (well, I haven't used v3.0 until tonight, but it seems to do act like 2.01a in this regard)

In the end, I'm left to wonder if this behaviour is the new norm? Perhaps it's what the note "- fixed table editing for the transpose column" alluded to? Or is it an unforeseen effect in this release candidate?

Greetings from Norway

Hey thanks. The fixed transpose column was purely an editing thing.
Can you maybe provide me a 2.01/3.0 project so I can see what you mean and compare these myself?
I am not aware about any change in the randomization but you never know..

Ok, the project file should be on its way.

Btw: Forget what I said about the tables being 'locked' to the same scale.. not much variation to gain from that hehe. (it's been a minute since I checked out the RND/notes feature)
Reply
#8
I really love the NerdScope, it's such a responsive scope with a lot of functions and even tho it's hidden in a menu I think it really takes the nerdseq into a lot of other categories and pls keep it inspired as usual, such a great unit. would it be possible to deform the scope into a chromatic tuner with 4 Inputs simultaneously? Smile)
Reply
#9
(03-03-2026, 01:32 PM)JohnnyEgo Wrote: I really love the NerdScope, it's such a responsive scope with a lot of functions and even tho it's hidden in a menu I think it really takes the nerdseq into a lot of other categories and pls keep it inspired as usual, such a great unit. would it be possible to deform the scope into a chromatic tuner with 4 Inputs simultaneously? Smile)

The scope is only simple sidekick and will most probably not be updated in any way but stays as it is. They are proper scope modules for these things and I don't want to interfere with these in any way.

As for the request, this is impossible for several reasons:
- The 'sample' rate of the scope is theoretically a maximum of 1 millisecond because that is the handling frequency (1 kHz) that the mapping does offer and the mappingis the only source for the scope.
- CV inputs are not bi-directional but expect an input of 0-10 Volt. Oscillators are bipolar.
- Sampling of the CV inputs is also 1 kHz which makes it unusable for any audio signals
PLEASE use the search function if something have been asked or discussed before.
Every (unnessesary) forum support means less time to develop! But of course, i am here to help!  Smile
Reply
#10
As I've newly acquired the Nerdseq, I'm not sure if this bug is on the v3.0 firmware as well, but here goes:

I'm aware that Modular tracks can't share the same patterns as Sample tracks, however. If a pattern is created in on a Sample track and then deleted, it is still impossible to add that same pattern number afterwards to a Modular track. It simply jumps over that pattern number to a new one.

Is this a known bug or is it suppose to behave like this for some reason?

Edit: First post here btw, Howdy!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)