Jump to content

azslow3

Members
  • Content Count

    563
  • Joined

  • Last visited

Everything posted by azslow3

  1. I think it is unclear what you want... Do you want play only one instrument using whole keyboard at any particular time? Then already given answer should help. If you want switch instruments from keyboard, write what you want to use for that (f.e. pedals, knobs/buttons on keyboard, etc.). If you want play all instruments at the same time, so split your keyboard into several regions, then you can use Drum Map or several tracks with active echo and the same keyboard as input (or just omni), with forced channel and MFX event filter (MIDI FX plug-in) tuned to filter out unwanted regions.
  2. If that is possible (only M-Audio knows for sure...), AZ Controller can use it (well, that has to be defined in the preset...). Also note that with AZ Controller any button or pad (which sends messages) can be used as a "Shift" ("Ctrl", "Alt.", "CapsLock". etc.), to change what any other control(s) is(are) doing. But the button has to send something. And any knob (in finite CC mode) can be used as "N position" switch. I mean If "Shift+<<" is not sending separate MIDI message and you want extra command, you can define f.e. "Back+<<" for that (while still keeping "Back" doing "Undo" when pressing "Back" alone).
  3. If the strip can send pitch bend only and that is not editable, in Cakewalk you can use MFX which converts pitch bend to CC: https://tencrazy.com/gadgets/mfx/ , PW-Map. What you will see in PRV is still pitch bend, till you "render" that effect.
  4. I was targeting "is any sound can be driven by MPE?" question. But you are right, my post is probably "too academic" for musicians... So I better list just practical points: MPE should be activated on keyboard and inside VSTi to work correctly. Knowing how that is done (and what can deactivate it) may avoid confusion. Original MIDI Polyphonic After-touch is not a part of MPE. Some other messages are used differently. In other words, MPE keyboard can be used with MPE unaware VSTi, but it should not be in MPE mode. The "sound" can be wrong otherwise. the "sound" produced by MPE compatible VSTi in MPE mode from preset not designed for MPE may be not the same as in conventional mode. That is VSTi (and preset) dependent. Also editing MPE recording can be more difficult then conventional recording (DAW dependent). In other words, it is probably better use (record) MPE mode only in case MPE is really used.
  5. Unfortunately I have not found HammerPro88 protocol documentation. User Guide mention 2 things: "Output port for LEDs in DAW mode" and "most DAWs automatically configure the device". In BITWIG, are any LEDs follow the DAW? If some do (f.e. transport), but other don't (fader buttons), M-Audio has not foreseen the feedback for particular buttons (at least not "easy" way). If no LEDs have feedback... it may be worse checking output port is set correctly. But the fact "they are always ON" point to the first case (with incorrect port they should be "always OFF"). "Most DAWs automatically..." is probably not true. In particular DAWs installation instructions they suggest selecting the DAW on keyboard and use Mackie mode in the DAW. Theoretically they can support feedback for buttons and pads (so the possibility for a DAW control LEDs, pads colors, etc.) even in case Mackie mode is not supporting that, I mean in "native" mode. But without protocol documentation from M-Audio it is very hard (up to impossible) to deduct.
  6. If I have understood the specification correctly... there is no "required" ingredients at all to use (or imitate) MPE 🤪 "MPE compatible host" just means the DAW can save (record, edit) Note and CC MIDI events with different channels into one track and deliver them to VSTi "as is" (without modifying MIDI channel in the events). I think (almost?) all DAWs can do that. For editing, a DAW should support convenient editing events with one particular MIDI channel (without that editing MPE recording will be nightmare). Controller is not required, corresponding MIDI can be created in MIDI editor. But converting recording from not MPE keyboard to "MPE compatible" can be boring (till the DAW supports corresponding scripting... theoretically possible with CAL..). If VSTi is not MPE aware, it will take 15 instances of the same VSTi with the same preset to implement MPE with it. Also MIDI has to be specially processed before feeding each instance. Note that such structure is rather hard to do in Cakewalk. PS. depending from VSTi and DAW, special care may be required for switching on MPE (RPN 6 messages) and prevent switching it off (on stop). ------------------------- Finally, I think everyone who want use MPE should read MPE specification instead of MPE advertisements.... MPE is rather simple "trick" to allow changes in several parameters per note. Original MIDI 1.0 has foreseen just one (Polyphonic After-touch). Current MPE defines 3. All that just to support keyboards with extra sensors per key.
  7. For the 3d option to work, the slider should send CC11. It will be assigned to AZ Controller logic, so initially CC11 will not come throw but modify WAI volume (or something according to preset logic). If the control is put in the group "A" and that group is toggles, it will no longer block CC11 and so it should be usable in plug-ins. And in that case it will be be processed by AZ Controller, so will not move WAI volume. But switching presets on the Keyboard, so control is sending something not assigned in AZ Controller, is probably simpler approach to achieve the same goal. "Groups" in AZ Controller are primary for controllers which can't switch hardware presets easily or when "advanced" logic is used (f.e. auto move some controls to/from pure MIDI mode when particular VSTi is in focus... some AZ Controller users experiment with funny configurations, may be just because that is possible 🤪 ).
  8. It depends from the version of Session. "SONAR" edition was bound to Sonar. General Strum Session 2 has serial number (as other AAS Session plug-ins, Platinum users could get those, in this case they are listed in AAS account).
  9. I have to checked what exactly is going on in this concrete preset for AZ Controller and so how easy/hard it is going to be to add "modes" for controls. But AZ Controller supports all kinds of plug-in control in Cakewalk, including Dynamic Plug-in Mapping (sometimes called just "ACT" since used in "ACT MIDI" plug-in) Direct Plug-in Control (used in Mackie Control plug-in) dynamically including/excluding controls from surface plug-in operations (not available in other surface plug-ins). The last options allows at run time "de-assign" let say sliders 7-8 from AZ Controller logic, which effectively allows using them in VSTi plug-ins as MIDI input. For that, put controls in questions in some Group (in the Hardware Tab) and assign some button to toggle the group.
  10. I don't think people here joke about soundstage or audio imaging. And there was no claims audiophile equipment produce the same sound as studio monitors. But there is significant difference in opinions from where all that comes and what it really is... In other words, are DSD/768kHz/etc. really the "keys" to that "great audiophile sound"? Listening some recordings with studio monitors is way less fun then listening them on $100 HiFi player. My 20 years old €40 Yamaha computer speakers with "virtual surround" button pressed produce crazy soundstage, even when they stay near each other. But I don't think based on that someone consider using HiFi player for mixing own songs or computer speakers to check soundstage 😏
  11. If you are blind, there is related solution: https://www.azslow.com/index.php/topic,346.0.html But since LEDs make no sense in such case, the device stay dark all the time (and there is no on-screen display). So the solution is far from perfect for majority of users. Well, you may find interesting to work just with audio feedback: you can stay away from the computer monitor nor look at XTC, and still have all important information...
  12. I think that is a wish to use 8x oversampling, just for "safety" or really required by some crazy plug-in to work properly... In the second case it is better re-think and abandon the plug-in in question. It is definitively not written good when requiring such oversampling (and not providing it internally). In the first: that is "too much" in safety, do not forget that all less then a half of sampling frequencies are perfectly reproduced. Unlike 8x AA in graphics, extra high sampling rage does not "improve" anything. 96kHz by itself is already reproducing frequencies more that two times higher then any human (and audio equipment) can perceive.
  13. With me you can talk on this forum, my forum, WhatsUp/Skype/Phone. On this forum you can "talk" to Mark (current supporter of Mackie Control in Cakewalk), Noel (long time Cakewalk developer) and other Cakewalk staff people. That is not the same as "support" from Novation/Focusrite/M-Audio, where you normally can communicate just with (or throw) the "first level" support (people trained to answer common questions). People here not only know how all that works, but they are also able to modify related parts of the code in case that is required.
  14. Keyboard sends MIDI from each particular control to one port only. Which one depends from the keyboard settings, so currently loaded preset and activated mode. That is not something Cakewalk nor surface plug-in can influence (till plug-in knows how to switch mode/preset...). The "bug" I have mentioned was rather confusing, in your example even so you could see let say "MIDIIN2" in the preferences, the DAW was actually using "LKMK3" instead. If that can happened in the current Cakewalk version I am not sure, I have not observed the effect for a while (but I try to be careful with connections...).
  15. My first guess is a bug in Cakewalk, it likes messing with MIDI assignments of Control Surfaces (started in some version, then was changed/improved/modified, but I am not sure it is eliminated completely...). "AZ Controller" will not help if that is the issue, it also use Cakewalk MIDI (for that reason I was thinking several times to work with MIDI devices directly, but mentioned "one port for everything" case will be impossible then). General rule with Cakewalk: always start it with the same MIDI devices connected into the same USB slots. Unfortunately that is not always practical or even not possible (I have several MIDI devices and I don't want switch all of them on every time I start a DAW, I also use different audio devices with different settings and that is real nightmare in all DAWs I use, why even "smartest" DAW developers can't at least remember one set of settings for each interface, better several presets, is a good question...).
  16. Here is the explanation: some DAWs are able to route one port (a MIDI device from software perspective) as "normal" MIDI (f.e. as input to VST Instruments) and to control the DAW. Obviously messages for controlling the DAW should be filtered out, f.e. Mackie sliders are sending "PitchBend" MIDI messages, you don't want change the pitch in your synth when you change the volume of your track. DAWs in that category are Ableton and Cakewalk (while Cakewalk has no way to block the output to device in that mode, but that are details...). But most DAWs need a separate port (device) for DAW controlling. And if some device pretend it can emulate "standard" controllers, like Mackie, it can't send keys to the same port. That is not technically possible, even in Cakewalk (with Mackie surface plug-in). Many controllers, including Lauchkey, are Ableton oriented. And so the have (or had) just one port. But if they want support "other DAWs", they have to implement at least 2 pairs of ports. And that has happened with MK3, they just want attract more users. -------------- Which ports to use depends from what the device is sending, in most controllers (Launchkey including) that is freely configurable. In factory presets other then for Ableton, "DAW controlling" messages are send throw "DAW controlling port". And so this port has to be used to catch that messages. -------------- "ACT MIDI" not only has strict limit on the number of controls, it also does not show the messages it receive. So you can't easily check which port you want. Another limitation is just "banks" based switching what particular controls operate. That in practice is not flexible, especially with limited number of available controls. How a control modify target parameter is also fixed, just "jump" and "catch" are possible. That is not always practical, at least not for all cases. -------------- "AZ Controller" does not has these limitations. It supports unlimited number of possible controls, modifiers and combinations. It shows last receive MIDI message. I has several fancy modes for finite hardware controls. It also support several instances, so several ports can be configured in one preset (for the "Master" instance) or separately. And when device has controllable LEDs, it can use them as well.
  17. Bold parts can't work at the same time. Once MIDIIN3 is assigned to Mackie, all messages from it are blocked. And device is not sending keys there in any case (till in custom setup). In general, you mention 3 different methods to use MIDI controller in Cakewalk: throw Control Surface plug-in (AKA ACT, even so only one of such plug-in has "ACT MIDI" in the name). That you activate with Cubase mode on device and Mackie plug-in in Cubase mode in Cakewalk. You doesn't mention/use that in "Testing" part. "Remote Control" of particular Cakewalk elements. In "Testing" you recommend move controls "all the way" during learning. From my knowledge Cakewalk is not sufficiently "smart" to learn control type/range. It just take the first message and use corresponding default value range. MIDI learn inside VSTi. For 2 and 3 important is "simple" type of the message the control sends. In general on devices without touch function nor encoders that is default (till in Mackie/HUI imitating mode and the mode is activated), so I guess any "not DAW" preset for Mini can be used for both. For 3 important is enabled echo on the track. So keys should work ("produce sound"). In Cakewalk that is default for focused track, but some users "manage" to switch that off. Note that "ACT MIDI" supports an alternative way to control plug-ins, "Plug-in dynamic mapping" (also at many places/texts called just "ACT"...). Mackie does not support that way (it uses yet another way, "Plug-in direct control", which is not supported by "ACT MIDI"...). There are several differences between MIDI learn inside plug-in and plug-in controlling throw surface plug-ins: MIDI learn only works for plug-ins with MIDI input and only when that input is active ("echo on"). That means most FXes are not controllable that way (the have no MIDI input). Surface plug-ins can control any plug-in which expose automation parameters, independent from MIDI inputs. MIDI learned changes are recorded into MIDI clip, as "CCs" (assuming control sends CC). Surface plug-ins modify automations, so changes are recorded as automations. MIDI learned assignment are remembered by plug-in, this particular plug-in way. So can be preset dependent. Surface plug-ins mappings are saved separately by Cakewalk, they are activated any time corresponding plug-in is loaded, even with other preset or in other project. Note really a difference... But worse to mention: for Mackie, plug-ins mappings has to be manually written by user (also I doubt Mini in Cubase mode can select FX to control control). For "Plug-in dynamic mapping" all assignments are saved into 2 system-wide XML files, and sometimes Cakewalk can corrupt them, effectively loosing all created mappings (till good versions are backuped by user). Finally, the only "perfect" way to integrate Mini into Cakewalk is AZ Controller. Mini has more controls then "ACT MIDI" support and its hardware controls don't match Mackie and so ineffective in that mode. But no-one has created corresponding preset so far. People normally just stop at "working acceptably", with any controller 😏
  18. For (1). MIDI can't get "out of tune", even on tempo changes. But most Synth react on "PitchWheel" events. Note that Cakewalk by default has "automatic echo" on MIDI tracks, so the track should not be armed to process external events, it just does not record them. Also note that some synth have "MIDI output" and Cakewalks "All MIDI Inputs" setting for MIDI track include also all software MIDI outputs. So, my guess you get some PitchWheel (or other events which produce pitch shift in particular synth), can be from (a) MPK (you touch the wheel or it is "self generating", not so unusual problem with MIDI controllers), (b) you cat if from MIDI output of some synth (c) in recording you somehow have "relative pitch shifting" CC and you don't reset it on looping, so it accumulates with time. For (2). I guess almost no-one these days use synced arpeggiators in MIDI keyboard. They are good for hardware synth, but DAWs allow advanced arpeggiation in software. So it can happened related functionality is not well debugged in CbB.
  19. If there is ANY benefits in see/use/compare/correct multiple tracks, that is a good reason for Studio. Also some operations are simpler in Standalone, so not in a DAW. But update price is in fact higher, independent which functionality was "updated". That is why I have not updated 4 to 5 till now (it is finally reasonable priced, for the first time since introduction...).
  20. If NI S61 is too expensive, NI A61 can be a good option for you. With NI keyboards you get pre-made auto-mapping for NI (and some other) synths, when used inside Komplete Kontrol. There is no official DAW integration into Cakewalk, but with my integration (A61 and M32 have the same DAW/synth controls) you will have good (I even claim better than in officially supported DAWs) functionality (targeting the time you play, so quickly want change the track/synth, jog, open synth interface, start recording, turn metronome, etc. especially since A61 is not "near notebook" device and so using mouse/computer keyboard in parallel is not convenient). NI keyboards (all of them) have fine-grained encoders without raster. They are great for continuous parameters (volume, frequency, etc.) and "effortless" switching pages/modes, but far from the best option for live controlling a single synth, where finite knobs are more intuitive. Also note there are no faders and no pads. Better visit a store where you can test several keyboard. All of them have completely different feel when you press keys, unlike "digital pianos" there is no "reference" they need to imitate. Even when disconnected, you can sort out variants you definitively don't like (too "soft", too "hard", too "clicky", etc.). Note that S61 has Fatar keys with after-touch, A61 has "cheap" keys without after-touch. So the difference is way more then just build-in displays.
  21. That is one (from not so many) obvious possibilities which I periodically "discover" and then (completely...) forget 🤪
  22. You can use MIDI FXes, f.e. "CC Map" from https://www.tencrazy.com/gadgets/mfx/ Note that Cakewalk has no "pre-FX", so recorded value will be original. You can Process/Apply Effect/MIDI effects to render the change permanently. Also note you need MIDI track to insert these FXes, Instrument tracks show audio part FX bin, so you need to split it first.
  23. Well... a mixer was my second "audio interface", the third was VoiceLive Play (really that time I couldn't put all music equipment together into one place, so I had to use 3 computers as well, lol). Sure, I was also experimenting with ASIO4ALL at that time, more as an attempt to put VoiceLive Play and build-in Realtek together. Later was more interfaces and more software. What I mean, I took rather long way to RME. With many "aha!" and "omg..." moments. And I can't say it was not interesting. My current desktop setup is still a "workaround". I wish at least 8 inputs interface with low latency, which can work standalone. Some day I probably get UFX (or switch to Motu...). But the primary reason I don't have it already, is an attempt to come to the goal "cheap". I mean I have 8x8 + 2x4 interfaces permanently connected which do almost everything I need (8x8 can mix standalone). Just not perfect (latency and quality are not top). So I just try to recommend everyone to find something which perfectly serve wishes from the beginning. I mean I recommend the short way instead of workarounds 😉
  24. "FL Studio/ASIO4ALL/other generic" ASIO is visible from applications as ASIO. But they have to access hardware driver, which is not ASIO. Back in time, proxies sitting in the "kernel" could reduce latency a bit. MS has done relatively good job with WASAPI, on some hardware it even beats dedicated ASIO driver in latency. So for normal use, extra proxies are pointless. I agree that for using multiple interfaces in parallel (tricky in any case since that needs hardware sync between them) or using several applications in parallel they still can be used. But if that is "usual" activity, getting an interface which natively allow that is the best way to solve the problem. In my experience, "tricking" with fancy external software till some degree works, but can't be perfect (such software still has to deal with "laggy" hardware and Windows design). Note that is not automatically expensive. Like 8 years ago I have payed around 20€ for M-Audio Audiophile FireWire, it has own ASIO and allows other apps in parallel. And it is still my "default" interface for desktop 😏
  25. Well, unlike ASIO4ALL it has never corrupted all ASIO drivers on computer for me. And I was using Realtek ASIO not at "prehistoric" times (ASIO4ALL almost make no sense since introduction of WASAPI).
×
×
  • Create New...