I’m looking forward to the possibilities of native Lua scripting but I’ve been a Max/MSP user for years. So, I’m more interested in the native Open Sound Control (OSC) feature of 2.6 to tie my max control patches to this kick ass DAW. Doing scripting externally and mapping controllers that way.
Yes I know it’s a long way off and you still need to get 2.5 final released.
But I’m too excited about what this opens up.
I can see that the 2.5 beta has an OSC like address space in the MIDI mapping that is dynamically built. It would be great to have access all of these parameters via OSC at a full resolution.
Also, bi-directionally having OSC messages sent out upon say change of global viewpoint or anything else that happens in the gui or dsp would kick ass.
You too? We’re quite a crowd of people who are excited about the 2.6 release… Seriously: when I tell my nerd friends about 2.6 they suddenly get very interested in Renoise, even though they’re not making any music at all and haven’t used Renoise before.
The word is spreading. But it might be a good idea to lower the expectations, to avoid haussing/hyping and thus render no disappointments.
I somehow get the impression, from the little information we have about 2.6 so far, that the scripting will be strictly bound to the internal environment (Renoise), in a similar way that e.g. Reason’s Combinator device programmer is limited: we will have some options and are free to make the most out of these options. But we can’t for example grab data that is rendered from our scripting resources outside of Renoise itself just like that, or call external scripting/software to process some data which can get pasted back (in processed form) into e.g. Renoise’s pattern editor. I may be wrong (and I certainly hope I’m wrong here!).
Now, before we get another “Prepare Yourself for Renoise 2.6… [insert something here]” topic, let’s remind ourselves that the features of 2.5 alone are good, without doubt. The Good doesn’t deserve to become dwarfed by The Best, even if scripting really IS – by far – the coolest feature in all of Renoise’s history IMO. We just have to be patient and wait until the Team releases some official information about what we can expect in terms of limitations/possibilities, and give everything we can right now to search for bugs in the current 2.5 beta – an amazing release that actually rivals Ableton Live!
Lua has os.execute() which can call any external shell programs, which could then also fill the clipboard or write data back to HDD, which could be read into LUA again. Just wait until the final API is stable and published. Patience!
There are lots of things that you can do because there aren’t much restrictions. I believe os.exit has been disabled for security measures. But perhaps stuff like os.execute might get disabled as well if folks are interesting in abusing Renoise to exploit things…
Yeah, well this is what makes me a bit nervous:what true intentions do they have with the scripting language if they are no music producers or haven’t worked with music applications at all?
You can do stuff that has nothing to do with Renoise at all.
Bantai pointed me towards an IRC client library written in Lua some time ago. One might be able to implement it and voila:we have an internal chat client. That is a very prosperous thought about this scripting concept.
But one might also wants to use Renoise as a leap-board to execute malicious code on your system.
I doubt anyone is waiting for that, but i have no doubt there are many who want to try and exploit this.
Hopefully to be honest and report the how, why and the advise how to prevent instead of really using the exploit.
You express concerns about potential Renoise abusers who wish to exploit things. Of course, such concerns are very important. But since we don’t have any empirical/factual cases of abuse to refer to here, it all boils down to the question: Is it really plausible that there are such number of malevolent nerds out there (“folks”, if you prefer that term), that they are able to bypass the critical eyes of benevolent nerds? To release harmful stuff?
I don’t think so. The way I see it, the Fort Knox approach is contra-productive. Instead of having a possible Copernican Revolution in the music production world, you’ll just push potential benevolent interest away. People such as myself – who are highly creative and innovative (yes I am, both in my professional life and in my personal life). Suspicion, closed doors, high walls, guards, barking dogs, whatever – all of it assumes a context of malevolence, of a large number of disintegrating minds that are out to destroy.
Well, I asked that question myself. Not to myself, but to the guys who expressed the interest. My overall conclusion, based on the response, would be that some people simply are fascinated with cutting edge technology. Whenever a product steps outside the box and offers a lot of freedom for creative minds, such minds might also see an opportunity to show off with their skills for any reason (including portfolio building).
In regard to the people I have spoken to, I can assure you that they are nice guys with good intentions. I don’t know if that assurance will make you sleep better at night, but I do know that these guys are the kind of people who carry the world on their shoulders. Basically they think it’s just plain cool and wants to check it out. It’s a matter of esthetics: seeing innovative, nerdy stuff coming into existence constitutes a value in itself for most innovative nerds.
The last sentence is really what all this boils down to, ultimately: Do we believe that most people are good guys or do we believe that they are bad guys?
For me, it’s not a matter of “hope” here. I don’t say: “Let’s hope enough Renoise users are good guys”. Given the nature of the Renoise community itself, it’s track-record so to speak, of openness, benevolence, support, suggestions, constructive feedback, etc – most Renoise users would support each other in this regard. That includes: warning others of malevolent scripts (if any), educate about possible threats and dangers in scripting that calls certain external compiled executables, help each other to improve on scripts, etc, etc.
To take it to the extremes on a continuum, there are two possible approaches in regard to scripting: either you decide to start from the malevolent premise and close everything that might be used for something malicious, then slowly opening up more and more. Or you start from the opposite, have everything open and close stuff only if – and that’s a big ‘if’ IMO – they are abused to such extent that the community’s critical eyes are bypassed. Not very likely, eh? Just include a bunch of official “safe” scripts in Renoise (or on the website’s future script review section) and nobody will get hurt.
It is not about plugins itself. It is about a type of pitfall Microsoft felt into years ago with VBScript and macro’s. I’m not really fond of the possible idea falling down the same pitfall they did.
You compare Microsoft products that are exposed to billions of people with Renoise and Lua? Please explain this a bit further. What is the nature of this asserted pitfall? What circumstances made it come into existence? Do these circumstances apply in any aspect to the context of Renoise? If so, how plausible is the risk of falling down into that pitfall at all, given the resources to prevent it we currently dispose of in terms of understanding and actions?
I think you’ve all gone off topic on the OSC implementation.
Unless it’s being realized through Lua scripting.
Which going by… “you can plug in a monome with minimal extra work” suggests otherwise.
Anyway testing 2.5 pattern midi mapping via midi yoke from max then controlling with a my 64 now so I can’t complain at all, as this wasn’t possible a week ago!
This is perfectly fine actually. You don’t have to know LUA scripting to use any tools done with it. You’ll get a nice GUI and it integrates perfectly into Renoise, so that you won’t even notice that it’s LUA driven.
Not just are there worlds of difference between the Windows userbase and the Renoise userbase, also: Microsoft didn’t fall into any pit. “This software is provided as is, if you lose all your stuff, well, sucks.” is part of the standard disclaimer of all software I ever came into contact with.
USERS fell into the pit. Just shrug your shoulders. Problem solved. You cannot ensure everybody does not shoot themselves in the foot without severely restricting, well, everything.
There could a clear warning that buggy or malicious scripts could seriously mess things up. And there could be two or more levels of security: “going commando” (scripts can read, write and execute anything on the system), “sandboxed” (scripts can create and read their own files), and “crippled” (scripts can only do things that cannot do any damage under any circumstances). Kinda like a browser - “turn this on at your own risk”, problem solved.
But how to even discuss this before we get a feel for what would be possible with it, what Renoise exposes to the scripts etc.? I’d say let 2.6 come out first…
Yes you are right, so i pulled the issue to the developer area instead.
It is that some of the messages posted here made me consider some situations that might occur with the current stuff as it is implemented now. And restrictions on those areas necessary should not affect the real fun of the scripting itself. I doubt it will.
We’re quite a crowd of people who are excited about the 2.6 release… Seriously: when I tell my nerd friends about 2.6 they suddenly get very interested in Renoise, even though they’re not making any music at all and haven’t used Renoise before.
