Open magneto538 opened 6 months ago
Hmm yeah a proper interface in a programming language would be more friendly than a command-line interface. This would be a fair bit of work though.
Do you imagine you'd use the Lua just to run a sequence of commands. Or do you see being able to use programming language features like variables, loops, functions, etc., would be beneficial?
Definitely using language features would be a more complete solution. That way, one could programmatically build complex workflows and use other existing libraries to discover, prepare, and manipulate files on disk (e.g. Penlight).
Just thinking out loud here. I guess the bigger shift here would be to turn Signet into a library as well as a program. I'm not sure exactly how that would be done but it would require some significant restructuring. A lua interface could perhaps be bolted-on as Signet currently is, but I don't think it would be much better than just already using Lua to call os.execute
or io.popen
with Signet. Instead, we'd need a library-like access to Signet: an API with return values and an idea of when files are read/written vs when you are just manipulating audio data in-memory.
For now sadly I am not going to be able to do this amount of work on Signet. But I'll leave this issue open to review in the future.
Sure thing, thanks!
Can't you already use Lua to write scripts that run Signet? I don't think Signet itself needs to interpret Lua. I use bash scripts to run Signet commands, passing in parameters, performing calculations, etc.
I agree it is not needed, just simply wrap signet around Lua. I have examples of this in my Kontakt repository
Can't you already use Lua to write scripts that run Signet
Yes, of course you can, and no, I don't think it's a requirement. But I think there are obvious benefits about providing a scripting interface to a command-line tool — there are plenty notable examples. Even just being able to parse return codes from Signet commands to chain multiple commands together would be a big deal and allow to expand what Signet can currently do considerably. Again, I'm not saying this cannot be done currently, but it is arguably less friendly, even just for the reason that lots of string parsing and formatting is required (and that has a cost on memory too, which for a tool like Signet should be taken into account).
I don't think Signet itself needs to interpret Lua just simply wrap signet around Lua
To be clear, Signet shouldn't interpret or wrap around Lua. I'm suggesting to write a Lua interface (or any scripting language) and provide a compiled library that can be imported as a dependency in a script in some language, not the other way around. See the example I provided in the OP.
Considering that Lua is used widely by Kontakt makers using Creator Tools, it seems like leveraging the knowledge of Lua to write custom scripts using Signet would be an awesome idea. To do so, a Lua interface should be built around the Signet source, and a Lua binary should be deployed.
Example: