Alpha test program (or something like that)

[atom]

well the first Mac 32bits are there i don’t know hot to do 64bit builds yet, need to somehow boot to x64 mode to test it, i’ll try that later. Binaries are built in 10.5 compatibility mode on latest 10.6

[minimalist]

Many thanks atom! I’ll test it soon…

[minimalist]

OK, I’ve tested v5 on Mac (OSX 10.6.6). And… I feel totaly stupid – I don’t understand anything, sorry. I thought that I’m a little bit experienced with MIDI (after 14 years music producing), but I don’t get the idea how v5 should work. Ctrlr v4 I understood immediately… Is it possible that you have to be experienced in programming with v5 (I don’t have any skills)?

Did I missunderstood that you’re able to "load" presets for your synths (like in v4 you can choose different presets like: DSI Tetra, Virus, Little Phatty…)? Is this possible and how? I also don’t get the idea how to create your own controller assignments, though I read this: viewtopic.php?f=6&t=500 – but again: I’m too stupid for this. ” title=”Confused” /> Is there somewhere a short "manual/desciption" how to start (for people who don’t speak programmers language)? Sorry for all the questions, but am I alone with this problems?

Btw: The Vst and AU version is crashing my DAWs (Ableton/Maschine) immediately when I click in Ctrlr "LUA/Hooks", "LUA Console", "MIDI Mon", etc. The standalone version does not.

[atom]

Well you need to create your own controllers for any device (for now v5 does not have any built in, i didn’t have the time to do them).
You create a new panel and add controls (sliders, combos, buttons, whatever), change theirs properties (ho they look and so on), change their midi properties (midi message type, controller number, range).

Assign the devices you want to use in the Device manager, then for each panel assign an input and output device, at this point your created controllers should be sending the configured midi messages, and should
respond to the same midi messages.

I will write a manual and do a tutorial but i need to stabilize the code, and fix/add some features, that’s why it’s a pre-release alpha stage.

[minimalist]

Ahh Ok. So only to be sure that I didn’t missunderstood: The things you wrote about are not possible in the current version? So it’s not possible to control synths yet? And will there be some kind of presets for some common synths like in v4 (this I understood because you’ve asked which synths we own for further tests). Thanks for your answer.

[atom]

well yes and no, there are no READY panels, but there is nothing stopping you from creating your own panels for your synths. and sharing those panels with others.

Right now v5 can do everything and more that v4 could you just need to make it do that. It’s all there. Once someone creates a panel for a device and decides to share it with us, you just open it in v5 and off you go.

[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” />

[netchose]

hi,

windows xp 32 DSI poly evolver Rack :

now I mostly need to send 2 messages sysex to change button
great Job

[minimalist]

Ohh my god I got it – v5 is dooope! And yes: It was my fault. I overlooked the most obvious thing: Instead of right-mouse-click I was searching for sliders, faders, knobs, etc. in the menus, submenues and subsubmenues… ” title=”Wink” />
The solution to create some stuff was so easy (right click on the empty field) that I didn’t find it. Ctrlr v5 is more than great!!!

But I experienced the same bug as in v4. If you automate a parameter in the VST/AU version Ctrlr v5 is crashing the DAW!! I really hope that it’s possible to fix it, because automations is one of the biggest reasons for me to use Ctrlr. Maybe I should registrate an account in the "Trac" for posting bugs… Would be nice if this could be more easy – I think the more easy it is to post bugs the more people will join and help during the beta/alpha phase.

[atom]

well i will fix any bugs that are reported, those with the automation, midi, vst are at the top of the list this is what i call the basic funcionality.

As for the questions above:

– the magner icon is something i’m working on, the working name is the "Witch Doctor" and it’s intended to recognize midi input and suggest what sort of controls should be created for those incoming messages (maybe the magnet is not the best idea but i had no others)

– i can explain it but i won’t since the program manager is a sketch and does nothing at the moment i don’t even know if the final version will look like this, that will depend on the feedback from the users, but a seperate forum thread will be set up for that

– sure i can add that

– depends on what you want, i focused on the engine side when doing v5, since someone wrote during the v5 phase that i should focus on that and forget about fancy graphics so i did. Generally all the images that will be ever used in Ctrlr have to be added as a resource. I can do skinned ui no problem it will just take time so it’s a matter of priorities

– i thought that the edit mode and non-edit mode are enough, if during the lifetime of v5 there will be a need for more, it can be easily done. I know i will write a "Ctrlr Remote" that will be touch friendly and will actually control a Ctrlr launched somewhere else (a iPhone/Android/Tablet interface).

– Well all the obvious features.
— SysEx dumps (thats part of the program manager) (you can already do that using LUA)
— MIDI Feedback, Sending on any data on any MIDI device,
— Custom UI components written in LUA (you can already do that),
— Time based modulators (LFOs ENVs Sequencers) (you can already do that but it can’t be synced to the host)
— Audio based modulators (you could set midi values based on the analysis of the incoming audio signal, it’s level or some other properties),
— DeviceDB – a device library available over the internet, you’ll just type in your username/password from this forum and will be able to add/edit/download all the panels and programs shared by others
— Remote interfaces (iPhone Android Tablets) that will control Ctrlr launched on some other computers over the network but will also be capable of opening Ctrlrs on their own (assuming the remote control device has some sort of MIDI Output)
— probably something more that i forgot
— easier access to some nice internet porn (expected in v6)

[Kidney05]

"atom":va9lt3ch wrote:

— easier access to some nice internet porn (expected in v6)[/quote:va9lt3ch]

FINALLY.

[Coil]

Hi,

for better understanding:

i own sounddiver, so could i send midi messages e.g. filter cutoff from a sounddiver module/app and record that message in ctrl to make my own editor plugIn with ctrl piece by piece ?

[minimalist]

Hi. No, Idon’t think you can record MIDI messages (though I also thought about this very cool & eays feature request). But correct me someone if I’m wrong.

But the rest of Ctrlr v5 works as you imagine. Simply select a button, fader, knobs or whatever (there are many variations) choose the MIDI port and channel, the type of message (CC, SysEx, etc.) and create step by step your own plugin! You can also choose backgroud images, font types, font sizes, different colours for each stuff and many more… You can do almost anything individual.

This is simple and makes a lot of fun! ” title=”Cool” />

[Coil]

ok, thanks a lot !

i`m on a mac and i get the message that there is a newer version available than 307, but when i want to download, i always get the 307 version.
also in the standalone version the label called "Clipboard" is over the Buttons, so i can`t click them.
the component file kills logic when i want to open it.

[minimalist]

Yes, I already created a bug report about this issue (and I think you’ve made a comment?). The Ctrlr v5 Mac version is only a few days available, so I think there will be some updates from atom soon.

My music computer don’t have internet connection, so I don’t care about the updater. The latest versions you can find here: http://sourceforge.net/projects/ctrlrv4/files/
I think 307 is the latest, but wait a bit I’m sure that there are comming more.

[Coil]

can`t wait

[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.

[TonE]

Maybe under each ctrlr model we should have subgroups in the forum where users can share their created resources. For example graphics designer experts could just create various GUI background images and just share there. For example if you created a background GUI for Waldorf Pulse, just sharing under Waldorf Pulse > GUI, you could check there and select one GUI background which you like mostly, in various "Canvas bounds".

Another nice tool would be being able to split/save/export the whole "ctrlr v5 design process" into two orthogonal parts:

1. GUI part: Selection of components, colors, sizes, positions, images
2. Midi event definitions in simple text files, similar to those I sent to you atom, meaning using CSV format, let us call this CSV part

Then if we have any "CSV part" we can just create a new "GUI part" for it, and it should still work. So a second user could take a first users creation, change the GUI part, and reshare it, easily, without having to redo all the "CSV part" work.

[atom]

CSV files are not a good idea. An exported panel is a XML file (you can have a look at it in any text editor), but it’s a very complex structure and describing the MIDI stuff in CSV files is impossible, you have to remember that in case of some hardware most of the work will be done in LUA, simple byte-based definitions won’t be enough, you’ll have to go into bit operations packing and unpacking midi data from some old and forgotten formats.

At this point you can add 128 sliders and do a midi definition for them, someone else can take it and make it look nicer i see no problem. I hope to launch the DeviceDB soon so all this sharing buisness will be a click away.

[netchose]

Is this normal or a bug ?

configuration: Win XP 32 + mono evolver desktop => xmit all(transmit all MIDI data)

if I turn the rotary slider quickly, there is a tremor and the slider hangs

if I turn xmit off on the evolver the bug disappears

2 ° question. the combo modulator does not produce any MIDI message : something planned about this?

thanks

[Author]

Posts