Upcoming Synapse OB-Xa: Obsession

[mholloway]

There's no mono mode on the original, but there IS unison mode, and you COULD disable individual voice cards on the original. So, you'd get mono mode then.

I really hope he has not emulated that deficit or clumsy workaround.

Why? In a software emulation it would be as basic /commonplace as a box where you select the number of voices you want -- exactly how the Repro-5 works. What is clumsy about that?

[nirm123]

Sorry but that's not really what MIDI is for. Think of the things you are likely to need to do while you are performing a piece of music, those are the kinds of controls MIDI is for.

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

+1000 I use MIDI like this all the time.

it doesn't matter why was it invented originally. many of the tools which we are using today (and synths for sure) are not being used to achieve their original intended usage (in case of synths: emulating acoustic sounds), this is why we're keep on evolving. we're challenging the original intentions and finding new implementations for existing tools. a great point ED.

[e-crooner]

There's no mono mode on the original, but there IS unison mode, and you COULD disable individual voice cards on the original. So, you'd get mono mode then.

I really hope he has not emulated that deficit or clumsy workaround.

Why? In a software emulation it would be as basic /commonplace as a box where you select the number of voices you want -- exactly how the Repro-5 works. What is clumsy about that?

Ah, I thought one has to disable individual voice cards...
But if it's just a polyphony selector, fine with me. That's also how the mono retrigger mode is selected in Sylenth1, i.e. setting polyphony to 1 voice.

[Echoes in the Attic]

Sorry but that's not really what MIDI is for. Think of the things you are likely to need to do while you are performing a piece of music, those are the kinds of controls MIDI is for.

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

+1000 I use MIDI like this all the time.

it doesn't matter why was it invented originally. many of the tools which we are using today (and synths for sure) are not being used to achieve their original intended usage (in case of synths: emulating acoustic sounds), this is why we're keep on evolving. we're challenging the original intentions and finding new implementations for existing tools. a great point ED.

Midi is crap for controlling parameters that select different values like lists though. This is because midi is just sending a range of numbers (0-127). For hardware control you’re much better to use a system that relies on host parameter ids and values, which are bi-directional and you can actually see the values that are being selected. For example in Maschine or Novation SL or Ableton Push when you control a parameter you can see the values on screens such as the mod source in a list of sources for a list box. How would you ever do that with midi? You’d be blindly going through values in a list.
Automation parameters are the way to go for normal parameters as well since you get the actual units shown on screens.

[mi-os]

Sorry but that's not really what MIDI is for. Think of the things you are likely to need to do while you are performing a piece of music, those are the kinds of controls MIDI is for.

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

+1000 I use MIDI like this all the time.

it doesn't matter why was it invented originally. many of the tools which we are using today (and synths for sure) are not being used to achieve their original intended usage (in case of synths: emulating acoustic sounds), this is why we're keep on evolving. we're challenging the original intentions and finding new implementations for existing tools. a great point ED.

Midi is crap for controlling parameters that select different values like lists though. This is because midi is just sending a range of numbers (0-127). For hardware control you’re much better to use a system that relies on host parameter ids and values, which are bi-directional and you can actually see the values that are being selected. For example in Maschine or Novation SL or Ableton Push when you control a parameter you can see the values on screens such as the mod source in a list of sources for a list box. How would you ever do that with midi? You’d be blindly going through values in a list.
Automation parameters are the way to go for normal parameters as well since you get the actual units shown on screens.

Sorry, but it is possible with MIDI and/or host automation. The idea is to have a display which can display mapped parameters like mod targets. With a generic controller that would be more of a problem.

A modern control interface/protocol would be nice but isn't invented yet.

ps i'm talking about building your own controller

[EvilDragon]

There's no mono mode on the original, but there IS unison mode, and you COULD disable individual voice cards on the original. So, you'd get mono mode then.

I really hope he has not emulated that deficit or clumsy workaround.

Hope dies last.

A modern control interface/protocol would be nice but isn't invented yet.

It was invented and does exist but it's kinda-sorta niche, it's called OSC.

Also MIDI 2.0 will enable bidirectional communication at far greater resolution. Once hardware and software start supporting it

[mi-os]

A modern control interface/protocol would be nice but isn't invented yet.

It was invented and does exist but it's kinda-sorta niche, it's called OSC.

Also MIDI 2.0 will enable bidirectional communication at far greater resolution. Once hardware and software start supporting it

That's right. The question is how do we get developers to implement it? I see a bit of a chicken/egg problem.

[fmr]

A modern control interface/protocol would be nice but isn't invented yet.

It was invented and does exist but it's kinda-sorta niche, it's called OSC.

Also MIDI 2.0 will enable bidirectional communication at far greater resolution. Once hardware and software start supporting it

That's right. The question is how do we get developers to implement it? I see a bit of a chicken/egg problem.

I suspect implementing MIDI 2.0 full spec (or the most part of it) will not be cheap. Cheap was the biggest reason for the triumph of MIDI 1.0. I fear they were too ambitious with MIDI 2.0 specs, and that may be an obstacle. But I hope to be proven wrong, though

[Echoes in the Attic]

Sorry but that's not really what MIDI is for. Think of the things you are likely to need to do while you are performing a piece of music, those are the kinds of controls MIDI is for.

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

+1000 I use MIDI like this all the time.

it doesn't matter why was it invented originally. many of the tools which we are using today (and synths for sure) are not being used to achieve their original intended usage (in case of synths: emulating acoustic sounds), this is why we're keep on evolving. we're challenging the original intentions and finding new implementations for existing tools. a great point ED.

Midi is crap for controlling parameters that select different values like lists though. This is because midi is just sending a range of numbers (0-127). For hardware control you’re much better to use a system that relies on host parameter ids and values, which are bi-directional and you can actually see the values that are being selected. For example in Maschine or Novation SL or Ableton Push when you control a parameter you can see the values on screens such as the mod source in a list of sources for a list box. How would you ever do that with midi? You’d be blindly going through values in a list.
Automation parameters are the way to go for normal parameters as well since you get the actual units shown on screens.

Sorry, but it is possible with MIDI and/or host automation. The idea is to have a display which can display mapped parameters like mod targets.

If you midi learn a list, you will not see list values. Using a controller that simply reads the host parameter ID (automatable) values, then you can see the actual units or list values as the control changes the selection.

A modern control interface/protocol would be nice but isn't invented yet.

Why need another protocol when just using host automation parameters works fine? I wouldn’t know the first thing about how to make use of that with a custom controller screen, but so many controllers do it like NI Kore and maschine, nektar panorama, novation SL controllers, akai has one as well. They all do it, so it must be possible with your own controller.

[mi-os]

Sorry but that's not really what MIDI is for. Think of the things you are likely to need to do while you are performing a piece of music, those are the kinds of controls MIDI is for.

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

+1000 I use MIDI like this all the time.

it doesn't matter why was it invented originally. many of the tools which we are using today (and synths for sure) are not being used to achieve their original intended usage (in case of synths: emulating acoustic sounds), this is why we're keep on evolving. we're challenging the original intentions and finding new implementations for existing tools. a great point ED.

Midi is crap for controlling parameters that select different values like lists though. This is because midi is just sending a range of numbers (0-127). For hardware control you’re much better to use a system that relies on host parameter ids and values, which are bi-directional and you can actually see the values that are being selected. For example in Maschine or Novation SL or Ableton Push when you control a parameter you can see the values on screens such as the mod source in a list of sources for a list box. How would you ever do that with midi? You’d be blindly going through values in a list.
Automation parameters are the way to go for normal parameters as well since you get the actual units shown on screens.

Sorry, but it is possible with MIDI and/or host automation. The idea is to have a display which can display mapped parameters like mod targets.

If you midi learn a list, you will not see list values. Using a controller that simply reads the host parameter ID (automatable) values, then you can see the actual units or list values as the control changes the selection.

A modern control interface/protocol would be nice but isn't invented yet.

Why need another protocol when just using host automation parameters works fine? I wouldn’t know the first thing about how to make use of that with a custom controller screen, but so many controllers do it like NI Kore and maschine, nektar panorama, novation SL controllers, akai has one as well. They all do it, so it must be possible with your own controller.

Sure, host automation would probably the best way to do it right now. But the missing parameters problem is hindering me to try it.

I think NI has its own proprietary interface, so everything is possible for them.

[pdxindy]

Why need another protocol when just using host automation parameters works fine? I wouldn’t know the first thing about how to make use of that with a custom controller screen, but so many controllers do it like NI Kore and maschine, nektar panorama, novation SL controllers, akai has one as well. They all do it, so it must be possible with your own controller.

You run into the same problem as midi in that not all parameters can be automated. In Massive X for example, none of the parameters can be directly automated. You get the 16 macros and that is it.

That is the extreme, but many synths have parameters that are not visible to host automation.

[BONES]

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

So you'd agree with the guy I was responding to who thinks you should be able to do anything you can do with a mouse via MIDI. You know, change the skin or resize it, all of that stuff? Or did you just open your fat yarp without bothering to look at the context of the discussion? Of course, either way you are wrong. You probably weren't even born when MIDI first appeared so you really have no idea what it was designed for, only what you expect it to do today.

[mi-os]

A modern control interface/protocol would be nice but isn't invented yet.

It was invented and does exist but it's kinda-sorta niche, it's called OSC.

Also MIDI 2.0 will enable bidirectional communication at far greater resolution. Once hardware and software start supporting it

That's right. The question is how do we get developers to implement it? I see a bit of a chicken/egg problem.

I suspect implementing MIDI 2.0 full spec (or the most part of it) will not be cheap. Cheap was the biggest reason for the triumph of MIDI 1.0. I fear they were too ambitious with MIDI 2.0 specs, and that may be an obstacle. But I hope to be proven wrong, though

Development time costs could be an issue. I'm not a plugin developer, but shouldn't the vst sdk, for example, offer such functionality?

[wagtunes]

That's bollocks. MIDI is ultimately used for control, not just performance. So it is entirely legitimate to use MIDI for creating patches on the fly with a hardware device rather than a mouse.

So you'd agree with the guy I was responding to who thinks you should be able to do anything you can do with a mouse via MIDI. You know, change the skin or resize it, all of that stuff? Or did you just open your fat yarp without bothering to look at the context of the discussion? Of course, either way you are wrong. You probably weren't even born when MIDI first appeared so you really have no idea what it was designed for, only what you expect it to do today.

I was around even before MIDI and it boggles my mind what some people expect MIDI 1.0 to do when all you have is 128 possible controls, many of which are already assigned.

Personally, I don't expect MIDI to do anymore than what it did when I got my DX7.

[Noumena]

I was around when MIDI was introduced and it is used for wildly, *wildly* different things now than what it was "intended" to be used for, so the argument that "MIDI is for x" doesn't fit with the last... 38? years of history. I put quotes around "intended" because it was intended to be flexible and extensible so that it could do near anything you wanted so that another standard wouldn't be needed for a while (which would help to establish MIDI as the single standard.) That worked, thank god.

Anyway, I'm chiming in because what EvilDragon is talking about... "creating entire patches" through MIDI is actually one of the very few things that it was designed to do. Roland and other members of the original MIDI consortium wanted external programmers, librarians, etc, to be able to completely control every aspect about a sound module through MIDI: everything from parameters, to presets to firmware updates and settings. So, the very thing EvilDragon is speaking about (that being total control of all aspects of a sound module, inclusive of configuration, options, and other parameters) is and has always been part of the MIDI specification and the "intentions" of its creators. But don't take my word for it, check it out. Also, why always so argumentative?