[crayolon]

Dj Satana – the VST and AU versions work for me on Mac if I set them up in this order:

– Load Ctrlr VST/AU (but don’t arm for MIDI control/output just yet)
– Configure MIDI device settings
– Open the panel
– Choose MIDI devices from the dropdowns
– Arm (or ‘record enable’, or whatever) the channel

Now you should be able to play MIDI through the panel without Ctrlr crashing!

[crayolon]

Widy75 – everything Virus B cc/sysex parameter is the same on the Virus C, the only difference being that the Virus C has EQ controls and possibly some extra reverb type. I can’t remember exactly, but there are very few differences and with a comparison of the manuals, it should be easy to add the relevant controls even without having a Virus C to test with (I’m sure somebody else will test it for you ” title=”Smile” /> ). Anyway, there are no *conflicts* between B and C, only some extra values on the C.

Thanks, I’ll check those values on the Virus. I have HighPage set to Sysex, because my older Virus Ctrlr uses sysex for some extended functions, but I don’t think that makes any difference. If I get time, I’ll try going into editmode and bugtesting the Mac version of your Ctrlr (although I haven’t learnt much about the current version yet – any help from others would be much appreciated!)

[crayolon]

Widy75 – nice work, a great improvement on my Virus Ctrlr for the previous version of Ctrlr! I’m now linking visitors to my old Virus Ctrlr page (http://crayolon.net/virusctrlr/) straight to this thread so they can try your version first.

Like Dj Satana, it’s working fine for me in standalone mode (although the virus->panel dump doesn’t seem to work), but when I try to run either the AU or the VST in a DAW it crashes. Tested with Renoise and Ableton Live on Mac – I’m afraid I can’t test on Windows at the moment. The panel loads fine, knobs can be turned etc. but as soon as it receives MIDI input it crashes.

Oh, and as h3moglobin says, we need more bank values in the dropdown! My Virus B with the latest OS goes from A to H; I guess the Virus C goes even further…

Cheers ” title=”Smile” />

[crayolon]

A clean, menu-free, uneditable, inviolable, ‘Player’ would be great for day to day usage of Ctrlr panels which are out of the development process and are in general use. Ideally, there would be some generic user options exposed – probably just MIDI I/O device, channel, bank and patch selections. Right now, I’m not too happy about having to switch to ‘Edit’ mode to set those options, since it’s very easy to accidentally fuck up the layout with an errant mouseclick.

In Ctrlr4, every time I loaded a Ctrlr VSTi, I had to click in the main body to focus (otherwise the file menu options were all greyed out), then go to Options to set all my I/O. Will we be able to set persistent default settings in Ctrlr5 to save lots of time?

[crayolon]

I think I’m the only person other than atom who made any v4 Ctrlrs (correct me if I’m wrong, atom?) and I can totally understand why nobody else could be bothered – it was fulfilling, but a lot of fiddly work and a steep learning curve, especially considering I’m completely rubbish at C++.

Ctrlr is for people who bought hardware on its own merits, not on the basis that they were buying an external dongle whose potential could only be realised if supplementary software was available. Software editors are never gonna cut it 100%, and when I run into limitations, I get off my arse and reach for the knobs and buttons on my hardware. ALL the commercial editors, as far as I can tell, are utterly appalling and overpriced. Midiquest is a disgrace and all the Access Virus editors I’ve seen are pretty but useless. Which brings us to the main point of Ctrlr, and the reason it’s such a great facility: sooner or later, if you want something done right, you have to do it yourself. And if you can’t be bothered, or don’t want to learn, there’s always somebody who’ll take £50 from you in exchange for something underwhelming. I’m glad atom doesn’t want to commercialise this – Leras: Ctrlr [i:2cny0ods]is[/i:2cny0ods] undercutting those other products ” title=”Wink” />

There are many debates surrounding the comparitive efficacy and ideological validity of FOSS and it usually comes down to whether people want to pay for a guarantee of some predefined level of quality or want to hold onto their money and hope for the best. Some of those who hold onto their money get frustrated because some open-source developers respond to ‘quality’ (or bug, or feature) queries with "well here’s the source, do it yourself!". And that’s not much good. But here, atom’s given us the best of both worlds: a free tool with THREE levels of community involvement. At one level, if we wanted to make changes, we could roll up our sleeves, grab the sourcecode and join in. At the user level, we just grab the plugin and hope for the best. But at the intermediate level, thanks to v5, we have a genuinely user-friendly means of taking matters into our own hands and shaping the project the way we want, without relying either on people to whom we’ve paid money (who don’t always offer a reliable support commitment) or open-source snobs who tell you to do it yourself.

Woohoo!

[crayolon]

Good point (and a quick search on the JUCE forums tells me that most of the discussion on there is pretty in-depth, beyond my knowledge). Thanks!

[crayolon]

Cool, I’ll chase after Jules and see if he can fix it. Seems like a lot of other hosts have figured out how to do this, so I’m sure there’s some technique out there that he can copy from ” title=”Smile” /> Cheers.

[crayolon]

I’m resurrecting an old thread here, but it inspired me to dig my old Midisport 2×2 out of the attic and test its multiclient efficacy between Ableton Live 8.1, Renoise 2.7b, MIDI OX (simpy as another MIDI client for testing, not for routing) and Ctrlr (v4 and v5) under Windows 7 32bit.

Ableton Live, Renoise and/or MIDI OX can share the same output on the Midisport with no trouble – regardless of whether Renoise is set to use WDM or MME – but for some reason, Ctrlr won’t share with anything else. I’ve always accepted this with my Edirol UA-101’s MIDI device, as I knew it wasn’t specced to be multiclient; the Midisport [i:ivmdr1pv]is[/i:ivmdr1pv], and even lives up to the manufacturer’s promise. So is there still a problem with JUCE or Ctrlr that could be investigated with the hope of achieving true compatibility with multiclient drivers? This would make my life a hell of a lot easier, and it would also probably cut down on about 50% of queries/complaints from new Ctrlr users who can’t figure out why it doesn’t work even though they believe (erroneously) that they’ve set up all their MIDI devices ” title=”Smile” />

Whaddya think, atom?

[crayolon]

It should be said that the above procedure is only necessary if you want to use the External Instrument device, or if you want that particular type of grouping (useful for some multitimbral work). The advantage to being able to control your hardware via Ctrlr and Ableton Live simultaneously is that a MIDI clip in Live can have Bank/Patch numbers assigned to it. If you don’t, however, and you just want to run up a quick patch to record a synth part in your song, you can simply bring in your synth’s output on an audio track and record it in realtime, and not bother with MIDI OX, MIDI Yoke or the External Instrument device.

I use either method, depending on what I’m doing. It’s good to have the choice ” title=”Smile” />

[crayolon]

Coil – you absolutely can ‘record’ MIDI messages, sort of. Get Sounddiver to send its MIDI output to a MIDIYoke virtual device, then select the MIDIYoke port as your input device in Ctrlr. Now run the MIDI monitor in MIDIYoke and operate the control in Sounddiver. Whatever hex string shows up in the MIDI monitor; that’s what you type in the Ctrlr object’s sysex field.

It would probably be quicker and more reliable to simply get hold of the implementation docs for your hardware and get the info from that. That’s what I did for the v4 Ctrlrs I made, and I was even able to script an automatically-incrementing XML generator for some of the more laborious ones. The code’s sadly lost in the mists of time, but it’s obsolete anyway.

atom – thanks for those answers; all sounds good. Given that any graphics will have to be added as resources, how will they be stored? Can they be stored as binary within the panel file, or will they be separate files that need to be in the correct place so that panels can be loaded? I guess it doesn’t matter for now, but it would be good in the long run if the entire panel was stored in a single file…alternatively, if they have to be separate, I guess the panel can fall back on default JUCE graphics if the images can’t be found.

Good to hear about the porn; a built-in rating system would be good as well, for offering feedback.

LUA – looking forward to all the fun that can be had with that. Any tips you have, or little snippets, would be great!

Yeah, built-in noteon/noteoff passthrough, as well as sustain, velocity, aftertouch, etc. use the same CC values on all hardware synths (as far as I know), so it would be good to have that built in as default, along with an onscreen keyboard. The onscreen keyboard doesn’t matter much to me personally, but it could be handy if people want to test things in standalone mode without a hardware controller keyboard.

[crayolon]

My panel for the Virus is able to do a few things, but I’m mostly feeling my way around in the dark.

atom – if you could help me with a few questions, maybe they can eventually end up as part of a FAQ/guideline for people making their own? I know you’ll be doing this properly when a final release is near, but if I can get to work sooner, I’ll be able to add to the number pre-made panels available at release time ” title=”Smile” />

# What is the magnet icon for?

# Can you explain the functionality of the Program Editor? Also, is it possible to autogenerate a given number of patches? ‘Duplicate’ doesn’t seem to work, and it’s gonna take me a LONG time to create 127 individual patches for banks A to H of the Virus B ” title=”Wink” />

# Will there be an on-screen keyboard and some default, built-in functionality for passing NoteOn/NoteOff commands (as well as the usual other generics like sustain, velocity, etc) straight through to the hardware?

# How can I get knob graphics/styles into a Ctrlr5 panel? I still have my resources/code from the Ctrlr4 version of the Virus editor, but I can’t see how to migrate them.

# Will there be a separation of full-on, in depth Edit mode and user-orientated ‘Play’ (or ‘locked, or whatever) mode? If so, some options which are currently only available in Edit mode probably need to be made available when the panel is locked – like MIDI setup, channel, etc. Users will want to tweak that stuff, but they won’t want to risk messing with GUI values and mucking up the panel if they don’t intend to.

# Please could you bring us up to speed on the feature set Ctrlr5 is likely to have? Will I be able to add code that interprets sysex dumps from the hardware and stores them in Programs so we can have total recall and program sync in DAWs? As an extension of that, will we be able to use Ctrlr5 like a sysex librarian?

I’m sure some of these questions might seem impertinent; some might seem obvious…but the more people have an understanding of Ctrlr5’s capabilities and potential, the more people will get excited about wanting to make their own panels and sharing them with the community. I’m very excited ” title=”Very Happy” />

[crayolon]

Cool – here’s the panel and the bg image. There’s nothing substantial in the panel, just a few things I was using to test the MIDI I/O. All I deleted from the User dir was the .settings file, btw.

[crayolon]

Yup, thanks – deleting Ctrlr.settings allowed the exe to run. It crashes when I load my work-in-progress Virus editor panel, but I expect that sort of thing until the releases are stable. I won’t do too much work yet, in case I lose it ” title=”Smile” />

[crayolon]

The current Win32 executable crashes instantly for me too – I’m on Win7 Ultimate, 32bit. Reinstalled that VC Redist package (had it installed already, but repair/reinstalled to be certain); also tried running as Admin – no luck either way.

[crayolon]

Oh shit, ignore that – I just did New Panel and saw all the fun stuff laid out : D /

atom – forgive me if I’m jumping ahead here, but will I be able to import sections of the source/xml/etc from my v4 Virus editor into this, or will I have to start from scratch when making a v5 editor? I’m successfully sending CC from a slider to my JV-1010 (as it’s nearby) with Edit mode disabled, by the way. Great work!

[crayolon]

Standalone ran and exited smoothly with no crashes (yes, the VST version crashed Live but I expected that;)). I was able to select MIDI devices, but not do much else – looks nice though!

[crayolon]

atom – a quick update on my setup: Windows 7 32bit, Renoise and Ableton Live, Access Virus B, Novation Bass Station, Novation X-Station (sold the Nova and the Supernova II).

Of course I’d like to test, and naturally I can’t wait to bring my Virus Ctrlr up to date, so as soon as you’re ready for others to join the Ctrlr dev process, I’ll be waiting!

Btw, I still have my dev notes on the Nova/Supernova Ctrlrs, so although I don’t have the hardware any longer, I might be able to help fix stuff if things go wrong…

[crayolon]

Agreed, it sucks, but this isn’t what Ctrlr is for. Ctrlr is aimed at providing a software surface within a DAW which maps input to CC/sysex controls on hardware synths. The Axiom doesn’t have any hardware which can be controlled by CC or sysex; in fact, it’s got more in common with Ctrlr itself than it has with a hardware synth. The Axiom *also* maps user input (either by playing the keys or by sending commands over USB from a DAW) to a sound-producing synth, whether hardware or software.

Enigma is designed specifically to deal with the Axiom’s on-board operating system – it speaks the same language, and that’s a language M-Audio probably keeps to itself. Even if it were possible to change the Axiom’s mappings via CC or sysex (which I kind of doubt), Ctrlr would still be an inappropriate tool as it doesn’t do any sysex librarian stuff, nor can it store snapshots or controller templates. Enigma is still the best way to program your Axiom and will probably remain so.

I have an Axiom 61 (and used to have an Axiom 49), and for the most part I leave it set to its defaults. If I need to map it to software, I abstract the values in the DAW using things like Ableton Live’s MIDI-learn function. If I use it to control hardware, I send everything through a computer first anyway.

If you’re asking in general if somebody can create this, not necessarily with Ctrlr (because, like I say, this is not what Ctrlr is intended for), then yeah, I’m sure it’s possible…but it would be a massive amount of work and would mostly be replicating work that M-Audio have already done. I doubt you’d find a programmer who could get interested in reinventing the weel, even if there was an opportunity to make it a *slightly* more user-friendly wheel ” title=”Wink” />

[crayolon]

That was me, atom ” title=”Smile” />

(I *think* you don’t have an Intel Mac; I could be wrong about that, though!)

Yeah, so I’m no longer able to build the existing Supernova project – and even if I could, I doubt I’d be able to figure out how to fix a Mac bug – but I was worried that it might be a fault with *all* the Mac builds. Either way, I hope there’s a solution!

[crayolon]

o/

I’ve noticed a glaring omission from my Access Virus editor (forgot to include controls for int/ext BPM sync or manual BPM control!), but rather than trying to fix it now (which would be difficult since I’ve had an OS reinstall and lost my C++ environment) I think I’ll wait for the next big Ctrlr version ” title=”Smile” />

[Author]

Posts