IX PatchBay III - Any requests?

[IXix]

The new version of IX PatchBay uses real machine parameters to handle the connections and since 24x24=576 (:shock:) params would be a bit extreme, I reconfigured the source to allow me to easily build different versions with different input/output counts, so you can use a version with as few connections as necessary.

Before putting together a package, I thought I'd ask what input/output configurations people find most useful? Does anyone ever need more than 8 outputs? Has anyone ever needed 24 inputs? What would be a useful selection of machines to include in the package?

@Oskari, if you're reading this, is there an upper limit to how many parameters a machine can have?

[mridlen]

I don't really comprehend what IX Patchbay is used for. I'm assuming it's some sort of aux bus type thing, but quite honestly it confuses me a little on how to actually go about using it.

Edit: Patchbay not Split

[pac]

A version of Patchbay with one parameter for each connection sounds really cool. The ability to make "repatching" patterns is interesting, and I sometimes approached this by taking the "mute" parameter from lots of cheapo amps and putting them all in a central patternXP.

I would probably always use a large-ish version like 16x16 (or maybe asymmetric 20x10), since I don't want to lock myself in. Then as soon as I start editing the patterns, I would certainly go in the PatternXP columns, clear everything, and only add those columns that I need. Otherwise it obviously wouldn't fit the width of the screen.

I guess another version that does fit the width of a normal screen by default would be good. I can fit a bit over 80 switch-type parameter columns on my laptop screen, which gives us something like:
(9 inputs + 1 separator) x 8 outputs = 80 columns in pattern view

Just some wild suggestions.

Edit: Actually, scrub that, please make a custom pattern editor where the change of connections over time is visualized as a volumetric 3D cube. We can manipulate it Jurassic Park-style with a dedicated glove, and there should also be a game mode that turns the cube into superimposed Doom levels.

[szaszhareen]

I don't really comprehend what IX Split is used for. I'm assuming it's some sort of aux bus type thing, but quite honestly it confuses me a little on how to actually go about using it.

ix split, at it's most basic level, works like a keyboard split on a hardware synth, allowing you to select a range of notes where a specified output will be played when those notes are triggered. it's great because it's also a peer machine, so you can control several machines at once with one midi controller. it's fairly straightforward, try it out and start up a thread if it continues to befuddle.

patchbay i have, but haven't tried yet. it'll be interesting to see how this thread develops.

[mridlen]

Er... sorry I meant IX Patchbay... I use IX Split regularly.

[IXix]

I don't really comprehend what IX Patchbay is used for.

It's so you can switch machine connections on the fly. The previous versions used a command/argument system to set connections in patterns, which worked fine but was a bit awkward. Version 3 will have a switch param for every connection.

I built a 24x24 version today and it works fine. I'll release something soon but I want to try an alternative strategy for the pin params first.

[snowglobe]

Randomization option(s) would be cool.

What would be a useful selection of machines to include in the package?

aaaand now I'm confused

p.s. lol @ pac's edit

[IXix]

Randomization option(s) would be cool.

Randomise the patch? You'll be able to do that anyway with the parameter window preset stuff but I suppose I could add a button to the GUI.

[snowglobe]

Randomization option(s) would be cool.

Randomise the patch? You'll be able to do that anyway with the parameter window preset stuff but I suppose I could add a button to the GUI.

I was thinking in terms of commands, like 'scramble existing connections' or 'n connections from all possible'.

[ohmegah7]

Randomization option(s) would be cool.

Randomise the patch? You'll be able to do that anyway with the parameter window preset stuff but I suppose I could add a button to the GUI.

I was thinking in terms of commands, like 'scramble existing connections' or 'n connections from all possible'.

i like the sound of this

[IXix]

I was thinking in terms of commands, like 'scramble existing connections' or 'n connections from all possible'.

Pattern commands, menu commands or both? I'll certainly consider that but I don't want to spend too much time thinking about new stuff, so give me detailed requests and I'll see what can be done.

[pac]

Is the machine C++ or C#? Because in the C++ API there's a hack to change the number of parameters when the machine is being loaded. This allows you to set the number of I/Os (and pin parameters) according to the DLL name. Distribute a single machine (for example "patchbay_8in_8out.dll"), and the user can copy it and rename it to whatever they want (for example "patchbay_12in_4out.dll").

It works in the C++ API but being quite the old school hack, probably not in C# (haven't tried).

[snowglobe]

I was thinking in terms of commands, like 'scramble existing connections' or 'n connections from all possible'.

Pattern commands, menu commands or both? I'll certainly consider that but I don't want to spend too much time thinking about new stuff, so give me detailed requests and I'll see what can be done.

Pattern. OK, so specific suggestion: a global trigger param (bool): when a '1' is encountered in that column, shuffle the dots.

[IXix]

Is the machine C++ or C#? Because in the C++ API there's a hack to change the number of parameters when the machine is being loaded....

I've never heard of a machine doing that. Sneaky. It depends how hacky it is but that sounds interesting. Tell me more.

@snowglobe: More specific

[snowglobe]

@snowglobe: More specific

Code: Select all

	   Dictionary<IMachine, IMachine> ConnectionDict;
       bool shuff_;
	   
	   [ParameterDecl(IsStateless = true, Name = "Shuffle Connections")]
        public bool shuff 
		{ 
			get { return shuff_; } 
			set 
			{ 
				shuff_ = Value;
				if (!shuff_) return;
				List<IMachine> inputs = ConnectionDict.Keys.ToList();
				List<IMachine> outputs = ConnectionDict.Values.ToList().Shuffle().ToList();
				Dictionary<IMachine, IMachine> new_dict = new Dictionary<IMachine, IMachine>();
				for (int i = 0; i< inputs.Count; i++)
				{
					new_dict[inputs[i]] = outputs[i]; 
				}
				ConnectionDict = new_dict;				
			} 	
		}

[IXix]

C# gobbledegook

Too specific The more I deal with .NET, the less I like it. I must be getting old.

[snowglobe]

Get that C# offa my lawn!

[pac]

I've never heard of a machine doing it either, but after testing, it appears to be stable. It's hacky but not horribly so. The ugly-looking part is removing a couple of "const" attributes in MachineInterface.h. So Buzz expects the CMachineInfo * to be const but you can actually modify it. It shouldn't be a problem as long as you only modify it before Buzz ever reads it, ie. right when your DLL is loaded, so that's in DLLMain (or in CWinApp::InitInstance if you have that).

Since a piece of code speaks 1000 words, here's the source of a minimal machine that doesn't do anything but implements the hack. The user can make a copy and call it customparam_12.dll for example, and the machine will magically have 12 "dynamic" parameters.

[IXix]

removing a couple of "const" attributes in MachineInterface.h. So Buzz expects the CMachineInfo * to be const but you can actually modify it. It shouldn't be a problem as long as you only modify it before Buzz ever reads it, ie. right when your DLL is loaded, so that's in DLLMain (or in CWinApp::InitInstance if you have that)

Sneaky.

@snowglobe: exactly

[IXix]

I've never heard of a machine doing it either, but after testing, it appears to be stable. It's hacky but not horribly so. The ugly-looking part is removing a couple of "const" attributes in MachineInterface.h. So Buzz expects the CMachineInfo * to be const but you can actually modify it. It shouldn't be a problem as long as you only modify it before Buzz ever reads it, ie. right when your DLL is loaded, so that's in DLLMain (or in CWinApp::InitInstance if you have that).

Actually, you don't need to hack MachineInterface.h or do anything in DLLMain(). All you need to do is define your own GetInfo() and CreateMachine() instead of using the DLL_EXPORTS macro. I'm already doing that to set the parameter count using preprocessor definitions in the project configuration. Never thought to use the filename! Great idea! Easier for me to manage the project and better for the user because they can have exactly what they want. Thanks pac!