View Single Post
Old 12-31-2017, 03:42 AM   #404
Geoff Waddington
Human being with feelings
Geoff Waddington's Avatar
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,090

Originally Posted by Freex View Post
Hi Geoff & Co,
Just scan read thru the thread so far, and reading about the fx mapping, and single file vs file per fx.
I'd would be in the file per fx camp.

Reason being, having played around with Geoff's MCUC4 csurf.
I've rearranged everything in the c4fx.ini file while adding to it.
It wasn't in aphabetical order and I found it quiet cluttered.
The way I reordered things was to Arrange by vendor, then fx, and separate between each vendor

-------------- AVendor Afx name ------------
-------------- AVendor Bfx name ------------
-------------- BVendor Afx name ---------------

So I know it may come off as ocd, but I feel it speeds things up mapping wise.

I can only imagin the mess some people would leave the file, (judging by friends record collections lol.)

So for me single files or atleast single vendor files would be the way to go.

Imagine getting a new set of plugins, going into a stash and finding the complete maps, download and paste, job done, yeah sure maybe they're not labeled to your liking, but at least the hard work's done.

Maybe I'm too late to the party and that ship has already sailed.

Looking forward to having a play with pre-alpha later.
If we adopt VERY strict naming conventions that will be possible.

I think we should do that, starting right now !

Here's why:

A logical surface is made up of 1 or more physical surfaces (e.g MCU)

You give each surface a name (e.g. MCU1).

Surfaces contain widgets (e.g. Mute button).

You give each widget a name (e.g. MCU1Mute4).

A widget is associated with a MIDI message(e.g. 90 13 7f)

Here is a map entry:

MCU1Mute4 90 13 7f

Now we can make FX map entries with just a key-value pair.

Suppose you want MCU1Mute4 to bypass a certain FX.

Here is a map entry:

MCU1Mute4 Bypass

You have now tied that exact control to that exact parameter.

This makes maps internally consistent and humanly readable, but extremely verbose, and redundant.

The verbose we can deal with in a UI, the redundant is a problem.

Suppose you decide to remap a particular parameter.

That means you must change EVERY INSTANCE in every surface map, ugghhh.

I've been thinking about this a lot lately, and I think the only reasonable way is to adopt naming conventions.

That will be fairly easy for a person or a few, but things get tricky as more get involved.

Well, let's look at what that means.

It means we'll have incompatible naming conventions, making sharing non-trivial.

So, now you have the reasoning behind the extremely simple file format.

With such a format, it will be easy to write conversion tools, whilst still retaining the flexibility of being able to make up your own naming conventions.

Let's start the ball rolling, it's probably as painless as theses few steps:
1) Name the widget exactly as it appears on the surface -- the Play button is named "Play"
2) Name Channel components thusly -- "Fader1, Mute1, Solo1, Fader2, Mute2, Solo2...
3) Naming surfaces will be a bit harder, but a least if you run into a problem a simple text editor search/replace is your friend.

Note that we are just talking about file formats -- NOT user interfaces.

The idea is to get you folks up and running, then tackle the UI.

Getting the file format right will certainly help the UI design of course.

Open to any ideas...
Beta software Donate
Installation / documentation / source
Geoff Waddington is offline   Reply With Quote