Piano roll...Muahahahahua

Not an expert in LUA or APIs but I suggest whatever is needed to dock tools in windows like the the other tabs. It’s kind of saddening when the piano roll tools especially PRS is IMO better than FL’s piano roll are constantly overlooked :confused:

That would end all piano roll discussions imo

1 Like

This is why the tracker is superior imo, although I still use the piano roll tool PRS from time to time, chords and notes are EASIER to read like this. But unlimited note columns wouldn’t hurt.

Yet the visual appearance of the pattern view could be improved by a lot, making it less cryptic, l337 and early-80s to look at, and instead using modern, common visual concepts. e.g. giving the note a visual note length, using a block. Not rocket science, already would improve it a lot. But I am just throwing pearls before swine…

Here are some design guidelines for you:

  • Remove the … and the — in the pattern view, this is just an ugly workaround for everything good
  • Make blocks of notes, remove OFF, it sucks
  • Make note lengths and note blocks draggable
  • Make commands drawable (a pre-historic nerd mode still could be left in)
  • Make pattern scroll pixelwise
  • Make starting- and endpoints of notes pixelwise
  • Make the whole thing zoomable in y-axis
1 Like

Let the tracker be. It would be better to make something new than to polish a dated concept imo.

To me, the main issue is that the data structure and some of its concept are suboptimal from the start - stemming from old hardware limitations and the optimizations that had to be made during those times (bitops, lookups…). It’s a quite dated (although useful!) paradigm that hasn’t been properly adapted to the fact that CPU is now abundant. Data should be serial to begin with - a composite pattern with delta timed events. It gives a very simple playback engine with little code. Most transformations take place in the GUI with quite a low threhold to lay it out to your hearts desire - including zoomable note data, sample positioned note/effect events, arranger blocks… even dynamic structures if you want to go crazy.

Not sure if this is similar to how things are already handled behind the scenes… but the data format in itself feels very “hardcoded” or “locked in”, some way. Maybe it’s just a matter of the primitives of the current structure being badly chosen from heritage (like fx column where anything can happen, instead of automation lane per fx with uniformed commands).

1 Like

Yeah, but there are only few people on the planet willing and also capable of doing this rework of a “Super Renoise”. Taktik is omitted, because he thinks that Renoise is just too old structured for a complete reconception of the gui, and if you see the current new attempts, it always seem to end into “another oldschool tracker” or “completely-out-of-space-only-the-programmer-can-run-this-software” kind of work… You certainly need a lot experience with c++/rust/high performance coding and modern GUI APIs, and then a strict workflow to translate the concept to code. Might be a task for more than one… Also with experience in teamwork, maybe really agile (not top-down like nowdays, “pseudo agile”). And so on. So in the end more than one who also really wants this and is open to the most performant, most flexbile concept instead doing his/her nerdy stuff only.

I actually wonder if a browser rendering engine could do the gui job, but then I have no idea how you would actually transfer display data and input data in a very fast way without javascript… I guess by using api bindings or how this is called? Maybe without any kind of javascript for the gui (except for tools), and only using css and the plain engine… The firefox engine seems to be quite fast now and not bloated as the chrome engine. But maybe this is not a good idea at all. I actaully have no idea. Instead you could use iplug2 or something.

Personally, I’m mostly interested in just making an oldschool tracker for chiptunes! (the way it should be done™)

Prototyping is underrated. So far, I’ve made a gui/layout framework in LÖVE using a composite design pattern (like Viewbuilder) and I’m working on the playback engine. The best prototyping environment for a playback engine imo is Renoise, funnily enough. You just test it offline by writing to a waveform, then use it live in LÖVE (which is basically luajit + SDL2). Keep OOP clean and easily convertible if the urge for C++/C ever arises.

I know someone who recently made steinberg-free VST headers+host and plugins and can probably help if you want to make your newschool tracker :slight_smile: Not sure about ffi or plugin capabilities in JS…(?)

PS. Keep dependencies and abstractions minimal.

1 Like

While you guys are talking about all this stuff that is 90% incomprehensible to me and which I enjoy reading, I just discovered that I can modulate individual samples within the same slot. for example, to make a snare drum I used a slot for the sine wave and a slot for the noise, now I have discovered that I can insert them in the same slot and assign them two different modulation paths, a whole new world has opened up for me. :exploding_head::sweat_smile:

1 Like

I think I didn’t know that either, also not sure, if I understand you correctly… Can you post a screenshot or so?

In reality it should be a fairly obvious and elementary function, but I didn’t know it was there.

So you mean that you can map two samples to the same slot, applying the exact same modulation? And before, you thought you had to use a new slot for each sample?

…different modulations. Imagine that you have to create a not very sophisticated snare drum, so you need a snappy sine wave and a “slap” of noise… before I used two different slots because I thought that each slot only had one envelope… now I insert both in the same slot, and I assign the sine wave to modulation 1 and the noise to modulation 2.

Modulation sets are very powerful when stacking samples/oscillators. We get up to 12 simultaneous samples and I think 256 modulation sets. Then throw in the instrument fx section and the possibilities are vast… Vast, I say!

2 Likes

Your videos are very useful to me, it’s from there that little by little I’m discovering many things, but I suffer from ADHD or something like that, so I have to watch the same video 16 times to understand one part of it, because in the meantime I’m thinking about a thousand others things.

2 Likes

I thought I was the only one :sob::sob::sob:, I watch them over and over lol

2 Likes

I seem to have some brain blockage or so :sweat_smile: Could you post an example song file? I still have no idea what you mean.

What is a slot here, a sample layer or so? So within one and the same modulation slot, you have multiple volume envelopes which can target individual sample sources?

If you have a snare consisting of a sine and noise, you usually want the sine to zap and the noise to be filtered and shortly volume decayed. This all within one modulation slot?

hope the video is explanatory enough. Slots are the spaces in the top right where you load your instruments (at least, that’s what I call that space). I could generate the exact same snare before, but using one slot just for the sine wave and one slot just for the noise. Same thing for the kick, I used one slot for the sine wave / for the body, another slot for the white noise which I use to generate the attack/click… Because I didn’t realize that Set Mods can be added/removed /move up and down… So I was convinced that each slot had only one modulation set… Again, if you want to make a double oscillator, one with a fast attack and one with a slow attack, I used two different slots , in other words, I was generating two different instruments that in reality I was only creating one… While there is a way to create the complete instrument without having to break it up into different sections… The same thing can be done with chains of effects, so if I want I can effect the sine wave in one way and the noise in another, without having to change tracks or anything like that.

1 Like

I agree with “unlimited” note columns, but I disagree about the easier readability of a piano roll when it comes to chords.

No thanks, I’m good. I don’t think that any of those suggestions would IMPROVE anything. Removing the … would make the visuals inconsistent, note blocks would result in ugly visuals (not clean anymore) and I like the note OFF. “Make commands drawable”, that’s something like graphical automation, right? And that’s already exisiting. But, as @joule said, you could create an own tracker from scratch that contains everything you desire. You’re capable of coding, right? I would check it out and let you know if it’s good. :wink:

2 Likes

As if the topic itself was cursed, this thread was fated to eventually become another episode of “fantasy football drafting” for features the software obviously is never getting and probably doesn’t need.

1 Like

That’s what I meant, my bad :sweat_smile:, think I put my comma in the wrong spot when I said “although I use PRS”. Chords are WAY easier to read on a tracker, especially if you know a bit of music theory. And let’s not even talk about drums…

What would be awesome is if we got a cool color stream up to the note off in each lane :weary:

1 Like

@slujr
I’m getting familiar with the phrases :grin: and it’s actually an approach I know well, I was just used to seeing it graphically different… after all it’s precisely as if the main tracker interface were the alternative to the conventional timeline where you they drag the rectangles…and the phrases were the alternative to the more conventional patterns that you program and then drag into the timeline…nothing more classic in environments like Ableton Live or FL Studio. This will help me a lot, I just learned to assign phrases to keys, so now I just have to program my phrases and then play alternating them…Whereas before I had to work on every single pattern in the timeline…

2 Likes