Hi,
(N.B. Was a quick experimental Linux program, that’s run its course 
)
Over the past few weeks I’ve messed around with client/server sockets in the Renoise lua API. I thought how would it look to write a simple program that transmits a track to a separate process that then plots it in a piano roll style:
Attachment 4637 not found.
Looks very cool!
shame I`m not on linux here as would certainly test this out.
Thanks Ledger 
Simple from the users point of view (as it does next to nothing.) A living nightmare for the developer! 
haha yes, I won`t even ask !
I’ve added a little bit of simple editing to the notes. If you do manage to get it to work and have a track transmitted to MiniRoll I’ll try and explain here.
First make sure you have version 0.2 from post #1.
Once you have a track in MiniRoll you’ll see that just running your mouse up and down the column display on the right hand side highlights the line. If you click your left mouse button on a highlighted line a marker is placed (a small red box with a cross in it) to the far right of the line. Again clicking the LMB toggles the marker on/off. You can mark as many lines as you like this way. If there are notes present on those lines the notes in the note grid are also marked red. For starters though just mark one line that has a note:
Attachment 4583 not found.
By marking it we’ve told MiniRoll that we want to modify this. Holding your mouse pointer position exactly as it it shown in the picture above (floating over the note) if you tap the ‘[’ key on the keyboard the note should drop down a semitone. Likewise the ‘]’ key raises the note a semitone. If you hold one of the shift keys and tap ‘[’ or ‘]’ it should raise or lower the note by a full octave. The change should also be shown in the Renoise track.
What happens if you have multiple markers and some of those markers have notes? If you float your mouse pointer over one of the note lines (it doesn’t matter which one, just make sure the mouse pointer is pointing to where a note is, like in the picture above) and tap ‘[’ or ‘]’ then all marked lines notes get raised or lowered.
A similar thing for the volume/pan/delay columns. If there is a number in these columns then you can modify the number using the same technique. Just float your mouse pointer over the volume, pan or delay column and tap ‘[’ or ‘]’ to raise or lower the amount. The instrument column isn’t used however.
If you have a lot of marked lines and you want to clear them, you can press the ‘c’ key. If you want to invert the marked selection of lines, you can press the ‘i’ key.
The ‘<’ and ‘>’ keys also increment and decrement the active column. Note that if you change the active column your selection markers are cleared.
One final very important thing to remember. The MiniRoll client (i.e. the Renoise tool script) and the MiniRoll separate window are not really synced at all. If you transmit a section of track down to MiniRoll then move back to Renoise, goto a different track (or even a different pattern!), MiniRoll is blissfully unaware of this. Don’t move back to MiniRoll and make modifications. It will either crash the tool or modify a track that doesn’t correspond anymore. Only make modifications if you know that you haven’t touched the Renoise edit cursor position (or pattern position) since clicking ‘Send to MiniRoll’. Well it is experimental 
For all its quirks I think it’s been an interesting little project
I’ve managed to get it to compile on my very very old laptop. So I added a 32-bit Linux version in the tar gzip archive (see post #1)
Technically it should also run on Renoise 2.8, the script isn’t using anything that was added in Renoise 3.0. Before you install the MiniRoll tool you could just modify line 3 of the manifest.xml file to API version 3.
The API version for renoise 3.0 is now 4. It goes up a whole step for each revision which is usually a .X renoise version step
Yes, I tried it myself with Renoise 2.8, but you have to downgrade the API version to 3 to get Renoise to accept it. Ah, the joys of downgrading scripts Ledger! 
doh! I think in my case it`s the joys of learning to read properly! 
Woah, I missed this thread until now?!
Nice, I will test this when I get home.
I tried it (running Xubuntu 13.10) and it works!
Really cool stuff.
Phew! It works…I wasn’t worried 
Cheers Dac for doing a quick spot of alpha testing during the ‘angry betas’ phase
Heh, well I don’t know what kind of feedback you are looking for. From the README it reads like a tech demo, and that you’re happy with it.
So my reply was more: Applause. Bravo. Cheers.
Your feedback is fantastic Dac! \o/ I was a little worried about it working for you or not (or anybody for that matter) as it is my own framework for doing the little GUI. The code is a bit haphazard and it needs reworking ideally. I suppose the readme does read like a tech demo. Am I happy with it as is for what it does? Well no, not really (of course it can be vastly improved.) But the problem is: how far do I take it? (or the better question is: how far can I take it? ) I’m very much undecided that’s why I left it as experimental.
The other questions are: where’s this going? So what’s the point here? I’ll be honest, I don’t really know and maybe not much Dac. I opened this topic for just two reasons initially. Firstly to demo that you can (kind of) talk to/from Renoise via another process (you don’t have to be constrained to the Renoise API for GUI work.) Secondly, because people didn’t believe me so I showed that MiniRoll does exist. Now just on those two points alone I hope that it inspires others to write tools that if they feel the Renoise API GUI system isn’t quite good enough (or makes things awkward) then maybe there is another option
How about wxPython server impl. to get the cross-platform winningness and easier dev cycle than c++? (I assume that the server’s doing nowt complex.) I’d be happy to hack on it if pianoroll isn’t in the pipeline for rns 3.x …
edit: and I’ve tried it on 32bit linux here, and whilst it’s not exactly feature-complete 
it works as you say it does :¬)
Hi Monotreme,
Firstly, thank you for offering sir. Good point (and yet another reason why I don’t really spend a lot of time developing this.) Is a pianoroll in the pipeline anyway? Unfortunately due to the way Taktik and co run their business we won’t know. So it’s anyone’s guess. If you were to pull my arm, then I would say that it is quite low down on their priority sheet. So for the purpose of this reply let’s assume that there is no plans…
Yes, good question. To be honest my choice of using C/C++ (this small program is predominantly C) was down to personal preference. I grew up on learning assembly language and C. Quick bit of history: I started programming a C64 about 25 years ago, Amiga, 486 PC… You get the idea. So I’m most comfortable with this. Plus I already had a very simple little framework for getting a window and be able to draw graphics in the window. The other little advantage is speed (although that isn’t really important in this case.) As you say using higher level API’s and a higher level programming language would help the developer (you may get a faster cycle. The chances are it would probably look more ‘professional’ as well.) Your example of using Python with widgets. I assume you are probably an expert in this area, I know only a small amount of Python, so I wouldn’t be of much use. But it would help to solve the cross platform problem. Just tell the user to make sure they have wxPython installed.
The server is doing nowt complicated at all sir. It’s not like there is any complicated DSP fast fourier transform math or anything. I’m by far not the worlds greatest programmer (complicated math? forget it) but a very very simple piano roll is within my ability. If you are interested in the small source code to the server I can PM it to you if you like. There is no magic Monotreme.
Okay I agree that it isn’t. But can I just say to people (in my defense) that I’ve put quite a bit of work into this. The end result (or as it stands at the moment) may be rubbish for the musician/user. I’ve had to do the simple graphics myself (and I’m not a graphician, so that is difficult!) I’m sure your implementation would be smashing Monotreme (no, I really mean that, I’m not being funny or anything (people on this forum have an uncanny knack of misinterpreting and twisting what people say I’ve noticed. It makes a very sickly, pathetic forum.)) You’d have widgets, clicky buttons, scroll bars etc… It’d be great. I wrote it like this because I don’t program very high level. So I haven’t got buttons, scroll bars, drop down menus etc… If I want that I have to program it all manually. Reinventing the wheel isn’t good I agree. But it’s just the way I program, very old skool, low level
Phew! I wasn’t worried Monotreme (because I know the amount of things that can go wrong! ) Ah I forgot, thank you for trying it Monotreme
haha, one of the best typos I`ve seen in a while!
LOL! Yes Ledger you are right that was a typo! And what a place to miss. Sorry folks, my fault. I shall correct. From a programmers point of view I shall try and negate
I had a 64, but didn’t get into programming until a lot later on. I started with a C training course, then had a job with C/C++, VB and Lisp, and my last programming job (I’m a home educator now) was a hotch-potch of C/C++, Perl, Python and shell scripts. I like Python, but am no expert. Am wondering if Kivy would be better than wxPython (this Kivy crash course might be of interest: http://www.youtube.com/playlist?list=PLdNh1e1kmiPP4YApJm8ENK2yMlwF1_edq)? Android and iOS thrown in can’t be bad, if custom widgets are possible/easy/fast enough.
That’d be interesting whatever happens
Hey, it’s very impressive stuff!
Lisp, now there’s a lot of parentheses Anyway, yes, I’m not an expert with Python myself (any little scripts I do in Python I have to have silly amounts of documention on hand because I can never remember all the details! Takes me ages just to print “hello world” to a terminal ) Kivy, looks great (they’ve done a lot of the hard work by the looks of it.) But as you say you would have to mess around and get an idea of speed (remember you’re working at what I consider a high level, so you generally trade computer efficiency. Having said that the other thing to take into account is if Kivy has a OpenGL implementation. So you could bring the GPU into play to unload the graphics a bit. MiniRoll is purely a CPU render of the frames (as far as I’m aware anyway with the X server.))
One of the main bottlenecks would be the Renoise Lua to server connection with the transmission of the UDP/TCP packets. To try and give you a very rough idea with my current Lua script for MiniRoll (I could’ve implemented it wrong mind you) if I ask it to transmit a 256 line track down to the local server it takes on my machine (not super fast, but not slow either) about 1 to 2 seconds. That’s transferring about 50-60 kilobytes of text (that’s about the maximum packet size of UDP I think per packet.) So a double packet transfer would be required for a 512 line track. So you are at least talking 4-5 seconds for that. You get the idea that bulk transfer of larger amounts of data isn’t ‘real time’ via Lua.
I’m glad you like it sir! \o/