(07-06-2019, 11:28 AM)MikkoM Wrote: (05-17-2019, 06:42 AM)XORadmin Wrote: Discussed before and i am not planning to do this at the moment. Most probably because the sample tracks differ quite a lot to the other tracks as they are 2 tracks in one. It would need much work and compared to many other features/requests it has a low priority.
(07-05-2019, 08:42 PM)XORadmin Wrote: (07-05-2019, 07:48 PM)MikkoM Wrote: As a professional SW Architect (22 years of experience in embedded systems and cloud computing) I really wonder what kind os mess the codebase is if this kind of basic feature is hard to implement. Hardcoded track types based on what number the channel is.... nope.. you absolutely do not do it that way.
Hey Mikko,
what can i say. Tell me more, what can i do to make it better? How should i do it then?
I'm always open for constructive critic and good ideas.
Cheers! T 
Quite impossible to say what the problem is without seeing code.
I assume it is pure C (?) however it is still possible to use object oriented programming paradigms to make code modular, reusable and extensible.
It is also quite important to remember that refactoring code IS "business as usual" and should not be feared.
Anyway, Nerdseq is really impressive accomplishment by one guy, so sorry if my first message sounded little bit harsh
Well, there is no problem. It is just not a priority thing aswell as still as mentioned before, the sample channels work in a different way.
While all other channels use 1 track / pattern, the sample channels use 2 tracks/pattern internally to allow different timings for the 2 samples within one pattern. So in reality you got 10 tracks instead of 8 and it would be easy to extract these to 10 tracks if it would fit easily on the screen. (and allow them to be any different kind of track).
If you saw earlier iterations of the NerdSynth (which shares the same source) then you will find out that these even got only 1 sample track but 2 extra visual tracks. And even earlier a complete different track assignment. So they are in fact flexible!
All tracks are set up to be also anything different. Thats not hardcoded! You might know if you used the expanders already.
But here is some information why i limit to 6 tracks: It is not a Midi sequencer. It also can sequence Midi op to 6 channels (and even more CC channels if needed) in a cool way, but the local cv/gate functions will always have highest priority as well as the expanders and main sequencer functions. Putting too much Midi data through one cable on different channels is not a good idea either and will cause latencies for the sequencing. (Which will be handled as a problem of the NerdSEQ then of course instead of the low data rate of midi in general)
I think 6 Midi tracks are more than enough to mess around with for a eurorack sequencer.
Also not every user has the Midi expander and/or 6+ external gear synthesizers to be controlled by midi. I think even only very few people have a setup like this. So the demand would be rather small compared to other killer functions which everone can use. (that doesn't mean that i won't add more midi features...but thats lower priority).
My 2do list (and the feature request list) is still long enough to add some cool stuff. And as you know i provide free firmware updates since the begin where each one adds more value to the sequencer and i will keep on doing this. But the pace is on me and the decisions are on me what i will and will not add with always an open ear for good ideas.
It is indeed pure c with critical parts in assembly while i wrote all libraries (except for FAT) myself. It is on many parts high optimized and reusable on many parts where it would make sense and wouldn't create overhead. Don't forget we are talking about a microcontroller, not an embedded linux system or whatsoever.
With aswell 20+ years of experience in all languages and professional jobs, from the smallest micros to high level desktop and server software i know what you talking about. And refactoring is not unknown to me. But also priorization and keeping the project clean is not unknown to me and thats why i decide for several things including to keep the (holy) sample tracks in all cases.
And don't forget that development on the firmware is just one part of all the work i have to do.
So, all relaxed and cool. This is an open platform (as in the forum) and every opinion helps (if it's not trolling, but thats not the case). And not the first time discussions helped me to think further...not in this case though. But still, all cool!!
...getting back to my weekend now and hoping to get the new firmware ready soonish...
