![]() Parts and events are the basic building blocks in Cubase.Įditing in the Project window is not restricted to handling whole events and parts. In Cubase, events and parts are placed on tracks. Tracks are the building blocks of your project. ![]() Each track is assigned to a particular channel strip in the MixConsole. Tracks are listed from top to bottom in the track list and extend horizontally across the Project window. They allow you to import, add, record, and edit parts and events. You must create and set up a project to work with the program. In Cubase, projects are the central documents. The Project window provides an overview of the project, and allows you to navigate and perform large scale editing. To play back and record in Cubase, you must set up input and output busses in the Audio Connections window. To use Cubase, you must set up your audio, and if required, your MIDI system. Many of the default key commands, also known as keyboard shortcuts, use modifier keys, some of which are different depending on the operating system. In our documentation, we use typographical and markup elements to structure information. The documentation applies to the operating systems Windows and macOS. Here you will find detailed information about all the features and functions in the program. This is the Operation Manual for Steinberg’s Cubase. I'll revisit this at some point.The following list informs you about the most important improvements in Cubase and provides links to the corresponding descriptions. If anyone fancies themselves an expert on win32 hooking and wants to have a go, please let me know how you get on. I've done a bit of refactoring in the process, and now have a place in which extra keyboard hooking could be done. Unfortunately although I did manage to intercept the events, and to stop them getting sent to the host, I couldn't find a way to dig out the character info needed from the ancient win32 structures involved. There's really only one possible hack that could be used here, and that's for the plugin to add its own windows hook to intercept the events before the host manages to get them. I can only assume that Cubase has some sort of hard-coded hack to see whether the focused window is some kind of special text control HWND, and if so, they allow the events to go through. I've looked at the Steinberg VSTGUI code to see how their own text editor class works, and can assure you that there is nothing in there which is missing from my code. Presumably a similar system i s used in Cubase, catching other keys as well, presumably it stops any that are used as app shortcuts. I've been using the Steinberg VST test host to debug, and it blocks all the spacebar events from reaching the plugin. The plugin code is completely legit - the windowing code is doing all the right things, but the host has got a win32 hook in place which is consuming the key events before they get anywhere near the plugin's window, regardless of whether the plugin window has focus. What it all comes down to is this: the host is being an asshole. This isn't the first time I've looked at the problem, and never found a good solution. Ok, I've wasted most of today struggling with this and am completely sick of it now and moving onto other things. ![]() The E, R & T don’t make it to peerWindowProc()'s WM_KEYDOWN or WM_CHAR Return DefWindowProcW (h, message, wParam, lParam) Īnd the pertinent log includes the following when I type QWERTY in the demo…Ħ:22:44pm CALLBACK windowProc: 256 - WM_KEYDOWN: 81, 1048577Ħ:22:44pm CALLBACK windowProc: 258 - WM_CHAR: 113, 1048577 - ComponentPeer::handleKeyPress - 81 - keyPressed: QĦ:22:44pm CALLBACK windowProc: 132 (WM_NCHITTEST)Ħ:22:44pm CALLBACK windowProc: 15 (WM_PAINT)Ħ:22:44pm CALLBACK windowProc: 257 (WM_KEYUP)Ħ:22:44pm CALLBACK windowProc: 256 - WM_KEYDOWN: 87, 1114113Ħ:22:44pm CALLBACK windowProc: 258 - WM_CHAR: 119, 1114113 - ComponentPeer::handleKeyPress - 87 - keyPressed: WĦ:22:47pm CALLBACK windowProc: 256 - WM_KEYDOWN: 89, 1376257Ħ:22:47pm CALLBACK windowProc: 258 - WM_CHAR: 121, 1376257 - ComponentPeer::handleKeyPress - 89 - keyPressed: Y send to: DefWindowProcW: " + String (message)) Logger::writeToLog (Time::getCurrentTime().toString (false, true) + " CALLBACK windowProc. Return peer->peerWindowProc (h, message, wParam, lParam) Logger::writeToLog (Time::getCurrentTime().toString (false, true) + " CALLBACK windowProc: " + String (message)) If (HWNDComponentPeer* const peer = getOwnerOfWindow (h)) Okay, I tried adding some logging: static LRESULT CALLBACK windowProc (HWND h, UINT message, WPARAM wParam, LPARAM lParam)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |