Page 1 of 1

Posted: 31 Oct 2008, 14:32
by antwan
Hello,

I've been lately thinking of a bigger scale suggestion.
It's perhaps a bit hard to explain but I will try. And I'm sure others can join in with there suggestions of possible implementation.

It's something one could call "Scripted patching" or "Automated patching". Truth is, I have no idea how to actually implement this.

Looking lately a topics like:

http://www.sensomusic.com/forums/viewtopic.php?id=1109
http://www.sensomusic.com/forums/viewtopic.php?id=1113

and thinking back at my own thoughts a long the way I've come to realize there might be a need for something like this...

So basically. Let's say I want to build some sort of looper. One of the great beauties of Usine is the fact that I can build a looper that works and looks exactly how I like it. The only thing I can't know for sure, as I build this looper, is how many layers of loops I am going to record in a live situation. So anyways, I end up building the patch deciding I will allow myself maximum 12 layers - a compromise between CPU/memory and what I know from previous experience, i.e. what's the maximum that usually will suffice.

Here's where we get to my suggestion.
Let's imagine that as part of the patch building process I could make rules that automate the extending and contracting of my patch during a performance. Let's say that I have each of these "layers" built as a sub-patch, containing the sampler-module to hold the recorded loop and all the other data flow modules. Then, outside these subpatches I have all the modules + other subpatches for the general functions of the looper. What if I could tell Usine:
- When "REC NEW LOOP" is pressed
- Duplicate this subpatch
- Make these connections

Or

- When "DEL PREV LOOP" is pressed
- Delete these connections
- And this subpatch

Etc.

This is just one greatly simplified example from - i'm sure - many, in which this kind of system could be handy - or just plain genious.

I actually do have some more specific suggestions in how this could be interfaced for us, the users, through a set of modules and perhaps an automation script-system, but I will have to take some time to prepare my presentation :)

Meanwhile, I hope people will join the discussion. Have I gone mad? Or is this a worthwhile topic? And most importantly, for Olivier, I hope this well-meaning discussion won't scare you to death.

greetings,

antwan

Posted: 31 Oct 2008, 18:20
by ethnix73
It seems pretty similar to what i was thinking about...somekind of a list for pre-configured actions....

Posted: 31 Oct 2008, 19:04
by SylvainT
Something like the macro...
The shortkeys for usual events, the macros for a list of events predefined.
Good idea, hard to implement isn't it?

Sly

Posted: 31 Oct 2008, 20:23
by amiga909
the macro idea is interesting.

yet I am not sure what exactly is missing in usine here.

some thoughts:
- adding/removing modules at runtime is likely impossible I guess. if you want this kind of flexibility you maybe need to program from scratch in C++ or similar in order to manage memory ressources

- recording keyboard and mouse actions could also be done by external software (eg. autohotkey)

- building macros: thats what subpatches are for?

- I dont want to stop enthusiasm here, for I am a dreamer too :)
usine is kewl but it cant do magic. if you want "a software MPC" be aware that decades of engineering went into a Akai MPC and a MPC covers many sequencer details you cannot know when you start building it. above all I reckon music applications are hard to code by nature (realtime, DSP, almost no usage constraints).

maybe I totally did not get what you mean, hope not.

Posted: 31 Oct 2008, 21:32
by martignasse
hi,

Interesting thread, you really want usine to go one more level up !

It's for sure a good idea, but very hard to implement in a practical way, like amiga909 said :
...music applications are hard to code by nature (realtime, DSP, almost no usage constraints)
The macro thing is certainly the easiest way to make it from the existing code and technology, but it will maybe not be very practicable, let explain :
adding/removing modules at runtime is likely impossible I guess. if you want this kind of flexibility you maybe need to program from scratch in C++ or similar in order to manage memory ressources
Not agree, usine is coded to manage this for us, and you already can create some new controls, and connexion, by and, with the audio engine running. For this part, it's ok, at least makable.

BUT... yes, there is a big but here. It expose you to some glitch and freeze. The main reason is, mainly the memory management, and variable initialization, how are clearly not friends with real time application.
So imagine the same thing automatized and quickly executed....not good for live.

Look at video games actually, if you wait a couple of seconds (sometimes minutes) before the game start, it's because the engine make all the stuff of initialization, resources and memory management before the 'real time session'.

Wait to hear what the boss have to say about this...

Posted: 31 Oct 2008, 21:41
by martignasse
building macros: thats what subpatches are for?
Not exactly, in my point of view, it's more like the folder concept in a tree hierarchy, a way to graphically manage the content (imagine all you're hard drive on you're desktop, you got it ?)

macro are essentially to manage or duplicate actions in a time point of view (like a batch, or redo function).

Posted: 01 Nov 2008, 00:48
by amiga909
if we are at impossible features for usine:

how hard would it be to have a 'export patch as VST .dll' function?

Posted: 01 Nov 2008, 11:35
by senso
many interesting questions.
1) one day Usine will be able to create modules and wires dynamically, for example modify the patch structure in a script.
I don't know when I'll implement that but it's in my mind...

2) about create a dll. The main problem is that Usine is not a simple VST filter but about 10x more complex. It use many resources of the computer. Also Usine needs lots of files so compiling Usine in a single file is an hard job. Not impossible, but I need time.