PIANO ROLL integrated in Pattern Editor! A Advanced Pattern Editor

Don’t worry, I’m also a strong believer in constructive (and even not so constructive) discussion.

This whole “note-off” discussion was spawned by the visualization of note lengths - I simply wanted to add my own experience with “loop based” composition.

So, to get back to that -

A tracker works differently from a piano-roll based DAW in more than the visual way - it also affects when and how notes are triggered.

Imagine you have a piano-roll that looks like this:

(the number represent beats, the vertical lines are loop start/end markers)

0 1 2 3 4 5 6 7 8
  | |
  | [C#4=================]
  | |

This is pretty easy to imagine: the C#4 is triggered on the second beat, and when looped it will stop until playback again reaches the second beat.

In Renoise, the result could easily be a different one

0 1 2 3 4 5 6 7 8
  | |
  ------------[C#4=================]
  | |

Here, the note is also triggered on the second beat_but will continue to play when looped_since the note is not released.

(the dashed line from 0-2 represent the note as it is played back when looped)

Yes, you can enable autoseek on samples toprevent this, but otherwise it is the defaultbehavior - also for plugins.

And that it works like this is a good thing - it opens the door to interesting creative possibilities. I mentioned how a glide command can make the C#4 an endless, “triggered once and then looping” note. And with 3.1, we even got a new per-song option to control whether automation respects looping or not, so it’s definitely something being considered.

This is one example of why I would want to insert a note-off in apparently strange locations - but also, why a note-length visualization isn’t always representing what is actually going on.

Still, I’m not against it - just wanted to add some complexity to the discussion :blush:

This is one example of why I would want to insert a note-off in apparently strange locations - but also, why a note-length visualization isn’t always representing what is actually going on.

Still, I’m not against it - just wanted to add some complexity to the discussion :blush:

Everything in this topic is complex ^_^. Can be also consider adding an activation option. Renoise to behave differently, for example, as I describe, or the like.I like to think that is not all done, and everything can be improved.

Don’t worry, I’m also a strong believer in constructive (and even not so constructive) discussion.

This whole “note-off” discussion was spawned by the visualization of note lengths - I simply wanted to add my own experience with “loop based” composition.

So, to get back to that -

A tracker works differently from a piano-roll based DAW in more than the visual way - it also affects when and how notes are triggered.

Imagine you have a piano-roll that looks like this:

(the number represent beats, the vertical lines are loop start/end markers)

0 1 2 3 4 5 6 7 8
| |
| [C#4=================]
| |

This is pretty easy to imagine: the C#4 is triggered on the second beat, and when looped it will stop until playback again reaches the second beat.

In Renoise, the result could easily be a different one

0 1 2 3 4 5 6 7 8
| |
------------[C#4=================]
| |

Here, the note is also triggered on the second beat_but will continue to play when looped_since the note is not released.

(the dashed line from 0-2 represent the note as it is played back when looped)

Yes, you can enable autoseek on samples toprevent this, but otherwise it is the defaultbehavior - also for plugins.

And that it works like this is a good thing - it opens the door to interesting creative possibilities. I mentioned how a glide command can make the C#4 an endless, “triggered once and then looping” note. And with 3.1, we even got a new per-song option to control whether automation respects looping or not, so it’s definitely something being considered…

I find it very interesting to contemplate the difficulties and complexities with the issue for implementing a new tool as this topic.Some things would be complex of represent them in blocks, as in commentary #36

Maybe you prefer because Renoise has always worked in this way.You are accustomed.The case is not the usual or custom, but do reasonable things automatically to make life easier for the user. So there are programs to streamline processes.

It’s not that i’m against any form of changes in Renoise, it has developed a lot since i started using it and i hope it continues to do so. What i meant was that i want to tell Renoise what it should do and it will do exactly that and not behave on it’s own. If i write just Y8 i don’t want Renoise to add OFF to that line without me telling it to do so. It’s really no big deal for me anyway, i’m used to OFFs and i have no problem with it and i think it does what it should, but i can understand that it’s not as intuitive and visual as dragging a box.

It’s not that i’m against any form of changes in Renoise, it has developed a lot since i started using it and i hope it continues to do so. What i meant was that i want to tell Renoise what it should do and it will do exactly that and not behave on it’s own. If i write just Y8 i don’t want Renoise to add OFF to that line without me telling it to do so. It’s really no big deal for me anyway, i’m used to OFFs and i have no problem with it and i think it does what it should, but i can understand that it’s not as intuitive and visual as dragging a box.

I wonder whether you really need to add a Note-OFF for the parameter Yx work.That is, work as in case 2).

Case 2) Not Work… Yx no work!!!

===========

C-4 50

… Y5

… Y7

… Y3

OFF

===========

In other words: Yx does nothing if is not the Note-OFF.It seems like the Note-OFFliaises with the top note. The Note-OFF Is it necessary to appear written?It can not do the entire job the Xy parameter?A comparison example:

Case volume parameter column (Work to grow the volume):

===========

C-4 50

… 40

… 20

… 10

OFF

===========

Volume parameters need not repeat constantly the note:

Case volume column (“Absurd to grow the volume of note C-4”) :

===========

C-4 50

C-4 40

C-4 20

C-4 10

OFF

===========

Note: in all cases, the instrument value not added!

Anyway, I agree with you, they are small things…

Another separate issuewhich relates to this topic (#43).Here:Help LUA: function to create a Group with two Tracks, one collapsed???

This topic has history, because it ends right where I wanted ( create a LUA script to sort the notes by octaves )

I have been opening the way to create a scriptto order the notes per octaves based on a selected track (“Original Track”).Selecting a track with a complex melody notes, the notes are ordered in 120 columns of note, 10 tracks “of octave” (octave 0 to octave 9) within 1 group. Finally, the octave tracks are empty, are erased.For me, this tool or script is very advantageous!

Currently, the script is deadlocked, due to “a bug” (rather lack of more code,I have called, “parameters lost”), caused by lines with “parameters lost” in column notes in the Original Trackbefore converting. joule has done a great job helping me in this concept.Basically joule just created the necessary code, he alone.He has been very kind!

Please, any forum member who knows LUA,are invited to examine the code to improve it.So far, the code can sort all notes and their parameters on the same line.If there is a lost parameter, without a note on the same line, it returns error:


C-4 00 50 40 FF …

OFF


Is ok!


C-4 00 50 40 FF …

… 40 <----- error (“lost parameter”)

OFF


This script is used to play notes in live with a midi keyboard first,and then order these clean notes in octaves… If there are not “lost parameters”, works!

Thanks to any member that helps! :slight_smile:

This screenshot reflects the idea (the blue columns is the same as all white columns after conversion):

[sharedmedia=core:attachments:6762]

In the white columns, you can visually understand the melody, and even find errors composition (Pattern Matrix in maximum zoom to better understand).

The velocity without note is used for polyphonic aftertouch.

The velocity without note is used for polyphonic aftertouch.

Hi ffx

Yes. If you use the current script to sort notes per octaves, after live recording with effect polyphonic aftertouch,will return error to find the first “lost parameter” (actually write a note-off instead,and stops converting the remaining notes).If the code is perfected in the future,also it works for polyphonic aftertoutch.This script does not understand of parameters, simply ordered what is written, but missing the condition of what to do when there are lost parameters (lines with parameters but without note).

The issue is to associate these “lost parameters” with the above note to that affect.In fact, more worrying is to achieve -avoid mistakes-.

To be more precise, you can usepolyphonic aftertouch with MIDI Keyboard after invoking the current script to sort notes per octaves, However, any “lost parameter” generates an error,in any case.

To understand us,I call "lost parameter"any parameter that has no right note beside, in the same line.You can follow this comment(in “Bug 5”). Here is the impasse! :blush:

All this to me is directly related to this topic. If you look well:

[sharedmedia=core:attachments:6762]

…It is very much like this:

[sharedmedia=core:attachments:6738]

:slight_smile:

Enjoy! :slight_smile:

Oh sorry, I misread… Keep on filling Taktik’s brain with useful ideas!

Oh sorry, I misread… Keep on filling Taktik’s brain with useful ideas!

TBH, taktik probably already has thought out the most useful ideas… among thousands of them.

He just doesn’t have the time required to realize them.

And we, as users, don’t have a clue what’s going on… or even if anything is actually going on…

I personally find it unfortunate that the Renoise developers have so little faith in the users that they feel the need to hide every tiny bit of information about development. Especially BECAUSE it’s such a niche product backed by passionate users; it would have felt even better with a little more open atmosphere where at least those users who had proven to be constructive and reasonable over a period of time (say 1-2 years) could get reading access to thealpha-testers’ subforum here (which is hidden unless you’re an alpha tester) and required to STFU in regard tothat information.

Somebody could now suggest that my preferences in this area (i.e. more open communication about the process towards the next beta) proves that I can’t handle the current situation, accept itandlive with it. But you see, I can handle it just fine. It’s just a preference, it’s not like I’m saying that Renoise devs are wrong. I just find it to be a very strange and counter-intuitive situation, based on the fact that most users seem to be very reasonable people. If some new feature is being worked on and turns out to be put aside by the devs somewhere further down the road because ofwhatever reason, most people would simply say OK and then leave it at that.

Again, and I’ve stated this preference in many threads before, let’s hope that taktik just says “oh well, to hell with the 2%cry-babies and 1% lunatics and 2% constant whiners…let’shavethe95% majorityat least knowa bit about where we as devs intend to go with this product, and what’s realistic and unrealistic tohope for…”.

TBH, taktik probably already has thought out the most useful ideas… among thousands of them.

He just doesn’t have the time required to realize them.

And we, as users, don’t have a clue what’s going on… or even if anything is actually going on…

I personally find it unfortunate that the Renoise developers have so little faith in the users that they feel the need to hide every tiny bit of information about development. Especially BECAUSE it’s such a niche product backed by passionate users; it would have felt even better with a little more open atmosphere where at least those users who had proven to be constructive and reasonable over a period of time (say 1-2 years) could get reading access to thealpha-testers’ subforum here (which is hidden unless you’re an alpha tester) and required to STFU in regard tothat information.

Somebody could now suggest that my preferences in this area (i.e. more open communication about the process towards the next beta) proves that I can’t handle the current situation, accept itandlive with it. But you see, I can handle it just fine. It’s just a preference, it’s not like I’m saying that Renoise devs are wrong. I just find it to be a very strange and counter-intuitive situation, based on the fact that most users seem to be very reasonable people. If some new feature is being worked on and turns out to be put aside by the devs somewhere further down the road because ofwhatever reason, most people would simply say OK and then leave it at that.

Again, and I’ve stated this preference in many threads before, let’s hope that taktik just says “oh well, to hell with the 2%cry-babies and 1% lunatics and 2% constant whiners…let’shavethe95% majorityat least knowa bit about where we as devs intend to go with this product, and what’s realistic and unrealistic tohope for…”.

Hi Fsus4, how are you?

I think this issue is not the place to discuss that.We discuss possible solutions on specific things, without putting to developers in the midst of the discussion. It is not necessary every time an idea comes with some visits.

I also have wanted to answer ffx on the issue of taktik.But really, is not the way.

We as Renoise users, can contribute ideas, because we love this software.Renoise Team with taktik to the head, they will do what they wish with their software.And nobody in this forum do not even throw them has the right to criticize. Nobody likes to receive orders about something that is not theirs.They know how to take care of their nest and how to satisfy users, and whether they should be happy to users who have purchased Renoise or those who have not yet done so, or both.

This is understandable when you create something great.If you create a program, you keep a small team over the years, you keep doing with him whatever you want!!!

I guess not report in the forum because there is nothing to report. And if any, shall be informed when it is secured, possibly in the release of a new beta.Unfortunately, there is a phrase in the presentation of version 3.1 which reads: "We have squeezed in a few long-requested features too, in an attempt to make Renoise 3.1 the best possible release."This is just pure marketing. They know they can improve many things still Renoise before adding things or new tools, Some areas are caught with pin (Automation Editor, Keyzones, Matrix Editor inclusive, and others…),that they are implemented in a basic way to work, nothing more; the best example is the Automation Editor. In most cases they have to do with graphic design and the lack of some basic functions.

But you can complain, and look at the view of the Renoise Team or taktik, or try to bring something to the user community, as if the Renoise Team not exist.The reality is bleak. I know it.This forum is empty!Most visitors are not even registered!People who can not even download nothing!!! is June, is summer!

I am aware that most of my contributions are ignored by the Renoise Team,but that does not matter because everything you do, is permanent in forum.Maybe in a while, the team Renoise regret not implement certain things, miss the opportunity. But much of the blame lies with the user community, who are not able to convince each other. There is no consensus nowhere!

For me, it is not normal that a contribution such this subject, has had four votes of stars, and is at level 2. The forum comes people to destroy, not to contribute. If you do not like, do not vote!They are proud to be contrary, because they think they are doing a pulse or something, and all I get is throw shit up. For my, all this topic that I opened, has paved the way to create a “stupid LUA script” to solve one of my problems in the composition (sort the notes per octaves).And that was thanks to forum members, not Renoise Team.I owe it to them.Stop obsessing Renoise Team or taktik.Try to bring to the user community to help each other on what you like, and do not take shit that you do not like…

Danoise, DBlue and others continue to help in the forum. Joule, for me, has proven to be one of the best members of the forum, because it helps others selflessly, without throwing shit through.If there were more people like that, things would be otherwise.So, yes, we can be all year discussing this nonsense. But I want a fucking tool to solve my problems! :blush: Sorry!!! :slight_smile:

I personally find it unfortunate that the Renoise developers have so little faith in the users that they feel the need to hide every tiny bit of information about development. Especially BECAUSE it’s such a niche product backed by passionate users; it would have felt even better with a little more open atmosphere where at least those users who had proven to be constructive and reasonable over a period of time (say 1-2 years) could get reading access to thealpha-testers’ subforum here (which is hidden unless you’re an alpha tester) and required to STFU in regard tothat information.

I totally agree!But maybe he wants to have full control over your product, and it is your right…I’d rather not talk Renoise Team.Let’s talk about Renoise! :walkman:

Hi Raul, I’m fine thank you. :slight_smile:

It’s notmy intention to hijack the thread. Just wanted to point outthat"filling taktik’s brain with useful ideas" isn’ttheroad forward to implement new features.He is probably already overloaded with a gazillion of useful ideas, but simply lacks the means (time, etc) to realize them. Not sayingit’s awaste of breath for users to keep pouring outideas for improvement. Sometimes it’sthe small finetuning that makes a bigdifference, and the devs do have atrack record forlistening to user experiences in such areas of improvement.

The pianoroll concept however… is somewhat a different story. But OK, let’s not talk teams and visions but instead focus on the product in its current state. While the pianoroll issue _prima facie_is about finetuning the visualisation of notes and harmonies, I think the real issue here is: shiftingsensory activity from ears to eyes.Visualising and editing notes graphically rather than alphanumerically introduces a can of worms that dig into the Renoise core and the essence of tracking itself. That’s whywe’ll walk in circles while avoiding totalk product visions (or the lack thereof).

Now my own preferred “solution” tothese issues would be: Renoise having a full C++ API thatwould allowthird parties todo stuff in Renoise that isn’t possible with Lua scripting.You know, not only codingnew modular DSP fx devices and synths,but also makingit possible tocompletely redesign the pattern editor and hook itup withstuff like pianorolls,linear arrangers, audio editors and score notation (sheet music notes).

Hi Fsus4.

In part it is normal that there are many people proposing ideas continuously.That is a symptom that are not completely satisfied with Renoise.If you look Renoise from a general point of view, you will notice accounts that many areas are still basic, bare minimum to work, without any frills. However, some things work not fine still.On the other hand, the lack of time is also a cheap excuse.I think not add some basic functions, some very demanded by usaurios are not of great effort for experienced programmers.If the end are not included, the cause is not wanting.

The tools with LUA language, for what I’m seeing lately is very limited time to add really useful features.In fact, some features may not work properly, and are “hidden”.This usually happens in whatever programming.

Now my own preferred “solution” tothese issues would be: Renoise having a full C++ API thatwould allowthird parties todo stuff in Renoise that isn’t possible with Lua scripting.You know, not only codingnew modular DSP fx devices and synths,but also makingit possible tocompletely redesign the pattern editor and hook itup withstuff like pianorolls,linear arrangers, audio editors and score notation (sheet music notes).

In reality this could be a disaster.I do not think there are many users on these forums able to create really useful tools, by the very ability of their knowledge, as well as the limitations of programation language ofRenoise.Check out the tools section.Some are mere patches of options that should be integrated Renoise (or not).Simple short scripts.A few are more sophisticated, but the great mass of users Renoise sure to ignore.I speak of really useful utilities that use all composers of Renoise.

I would like to Renoise had all the integrated tools, and not have to install anything else, unless you have a clear support (even including installation instructions and use).The more you know Renoise management and do a little research LUA language, you realize it.In fact, the tools or scripts of LUA for Renoise are like having access only to the rear wheel of your car.No access or screws that support it.In fact there is a huge lack of companionship when creating code in these forums.I mean raise 3 or 4 persons and say, let’s create this and we will do together, simply because one of them requires the tool…

In summary,most tools seem a customization of each creator user, and few users will actually use.Having some control Renoise API (a chunk under the hood),would be great.But who would schedule?If Renoise Team refine their software (refine what already includes,adding the basic functions also),perhaps there would be some brave personto think: ok, worth investing my free time to support, because the issue would be more serious and dependable.

In other words, people are disenchanted.Most people want a powerful and complete and fine software and leave “the rubbish” aside, without basic editors,created to muddle through. For example, the Automation Editor is “a pre-beta” inside Renoise and very cumbersome; Keyzones is similar, work areas with few options, and very basic. The instrument box does not allow order the instruments per groups (you have to use a slot name. What?), The philosophy is that, just and necessary, little more…If there are, exist a user is going to invest their time in perfecting a tool?

Renoise GUI is also poor in some places.You can save a theme XRNC, but not as basic as options to save a particular level of intensity of the colors of the tracks/groups, let alone differentiate between tracks and groups. Renoise not exploit the colors. And the details follow.Details that members of the forum can not solve (because Renoise is closed) and see desert on the horizon. Open the API, people are disoriented and Renoise Team also, because they must support these users to schedule, and therefore use your time.I do not think may open the API access.It’s protected with padlock on purpose. Logical. Most unfortunate: we can not ask for more for such a cheap program.

The only thing possible is to send a formal email to the support Renoise and ask.They kindly answer you…

I do not think there are many users on these forums able to create really useful tools, by the very ability of their knowledge, as well as the limitations of programation language ofRenoise.Check out the tools section.Some are mere patches of options that should be integrated Renoise (or not).Simple short scripts.A few are more sophisticated, but the great mass of users Renoise sure to ignore.I speak of really useful utilities that use all composers of Renoise.

You can’t extrapolatemuch from forum activity, unfortunately.These forums do not equal nor mirror the majority of registered Renoise users. In reality, I’d estimate there are quite many users off these forums who’re able to createuseful tools for themselves. That they aren’t interested in publishing their customized stuff isa completely different story.

The main point in having aC++ API would be for devs to say “hey look, we now give you even more powerful custom options to tailor Renoise according to your specific needs, sothat you canactually build that piano rollor DSP fx you always wanted”. This would, of course, be a completely different thing than scripting. More dangerous, more powerful.

Oh well. Time will tell where the Renoise project will end. But probably one reason you won’t see much forum activity from users is precisely because updates and new releases usually takes 1-2 years in between. Add to thatthe total radiosilence from developers on everything and anything related to development, visions, directions, whatever. As a user, you’ll stand there thinking “OK, so now we have Renoise 3.1 final out,come back in 1-2 years andcheck forRenoise 3.2 beta testing starts”.

And in the meantime, when somebody tries to write anything even remotely serious on the forums, the thread willget trashed by lolcat hooligans anyway. So there’s little incentive to actually be around these forums at all. Actually, I’ll probably also decrease my activity hereand justmonitor for news.

Thank heavens for ReWire and Redux.

You can’t extrapolatemuch from forum activity, unfortunately.These forums do not equal nor mirror the majority of registered Renoise users. In reality, I’d estimate there are quite many users off these forums who’re able to createuseful tools for themselves. That they aren’t interested in publishing their customized stuff isa completely different story.

The main point in having aC++ API would be for devs to say “hey look, we now give you even more powerful custom options to tailor Renoise according to your specific needs, sothat you canactually build that piano rollor DSP fx you always wanted”. This would, of course, be a completely different thing than scripting. More dangerous, more powerful.

Oh well. Time will tell where the Renoise project will end. But probably one reason you won’t see much forum activity from users is precisely because updates and new releases usually takes 1-2 years in between. Add to thatthe total radiosilence from developers on everything and anything related to development, visions, directions, whatever. As a user, you’ll stand there thinking “OK, so now we have Renoise 3.1 final out,come back in 1-2 years andcheck forRenoise 3.2 beta testing starts”.

And in the meantime, when somebody tries to write anything even remotely serious on the forums, the thread willget trashed by lolcat hooligans anyway. So there’s little incentive to actually be around these forums at all. Actually, I’ll probably also decrease my activity hereand justmonitor for news.

Thank heavens for ReWire and Redux.

Totally agree.This is an excellent analysis of the current situation.You’ve hit the nail!

  • Desert on the horizon for lack of information in the immediate future.Many people complain of not knowing the immediate future of Renoise.Too long between releases… The disenchanted people.
  • Lack of greater power (open the API) to create really useful things that most calls, as the simple idea of this topic: “a simple graphic pianoroll” integred in Pattern Editor, very simple(place notes, modify duration and little more).Or other heavier options for complete pianoroll.

“OK, so now we have Renoise 3.1 final out,come back in 1-2 years andcheck forRenoise 3.2 beta testing starts”.

Just heartbreaking! :smashed:

I do not have many years in forum as a registered user.But I understand that people are disenchanted, or conformist, because it can not do anything but wait.It is what it is.

Anyway, the situation is also understandable from the closed code.Open is dangerous and delicate for the issue of stability and performance also.Personally, if I were the owner of the code, not would open, quite we have with LUA.As I am a user, I want the open API.Dilemma!

Users can only show the Renoise Team them wrong on something, and that Renoise can be much more adding this or another thing.They decide and maintain the control.

Finally, I would rather forget pessimism, and do not write these things in the forums when the desert is seen,and is a string… Better to try to bring something and leave complaints aside, because the forum is full of them.Enjoy what we have and be constructive. Now goodnot allowing the existence a single bug. Open the API = more bugs???The issue is very delicate…

Well, since taktik has been the lead developer of Renoise for almost 16 years now (he started in December 2000 andwith the Noisetrekker code), we can only hope that he is actually still enjoying it. :slight_smile:

However. As I understand the situation, one crucial reason it took almost two years (December 2013 to October 2015) to finish the 3.0 to 3.1 release,was the increased complexity to managethecodeas a whole. This complexityfactor seems togrow worse foreverynewer Renoise version. So it would be somewhat refreshing if the devs actuallycarved out the pattern editor and made it into a new VST (or an enhanced version of Redux). That way we could have the Renoisetracking experience of VST instruments inside other DAWs.

Lots of Renoise users would probably be very happy with such progressivescenario!

However. As I understand the situation, one crucial reason it took almost two years (December 2013 to October 2015) to finish the 3.0 to 3.1 release,was the increased complexity to managethecodeas a whole…

Not is rather becauseneed more time just to include Redux and add the same new functions to Renoise?Perhaps the cause is the addition of Redux VST/AU, and not so much the difficulty of the code.If changing the complete GUI to a vectorial or something similar for high resolutions, then it is possible that the code was more laborious.So yes it would be worth waiting so long.People using Renoise main DAW, Redux always see in a second plane, something not required.

In my opinion, I would have preferred more refinement of Renoise, rather than including Redux.Focus all efforts on the Renoise DAW that it can improve a lot yet, simply adding useful little things here and there,and completing each type of editor (automation, keyzones, pattern editor, matrix…).Add Redux involves moving away from Renoise, and I do not like.

Question in the air: do you prefer a Redux, or Renoise with vectorial GUI and pave the way to perfect more?How to use the time?

What’s a piano roll ?

What’s a piano roll ?

6804 piano-roll.png