norfolkmastering

I'm trying to understand the difference between two different types of track selection: If I click on the track name, then the track name is highlighted. If I click on the track number (below the name) then both the track number and track name are highlighted. Could someone explain the differences between the two types of selection please.

Thanks for info. If I understand you explanations, I would need to create two 'dummy' MIDI tracks for every instance of Blue Cat Remote Control 3 I wanted to get external MIDI I/O to/from. Sadly not very practical when I would be using perhaps 40 instances on a project. I will contact the designers of the plug-in and see if there of a way to get direct MIDI access to each instance, otherwise I may need to find another VST MIDI controller plugin. Suggestions for alternatives would be welcomed!

I understand how to set the MIDI I/O for a Blue Cat control, no problems with that. I think I am struggling to understand the MIDI routing in Cakewalk. I have a large number of Blue Cat VST controls to get to the outside world and I don't see a practical way to do it? Why can't I see the Blue Cat MIDI in my MIDI-OX monitor?

Will do and thanks.

Thanks for the ideas. I can see that using screensets would allow a snapshot but I want this to be what happens when I open track or bus FX during mixdown. I think that means I would have to create a snapshot for every track and bus in my project. Is that correct?

When I'm about to work on a particular track during mixdown, I want to be able to open all the plugins allocated to that track (typically one EQ and one Dynamics) with a single click and get them to position themselves where I set them last time. Anyway to do this in Cakewalk?

I'm trying to use the Blue Cat Remote Control VST plugin to get MIDI CC values output from its control knobs to control an external hardware MIDI controllable device. Blue Cat's Remote Control is a VST3 plugin and supports 'Enable MIDI output' which I have ticked. I'm using MIDI-OX to monitor MIDI activity but I just can't get any MIDI output from the plugin. All help would be appreciated!

Thanks, now I understand.

Can I ask what you mean by 'in the Media Browser'? Do you mean where the .cwp file is stored in Windows? And when you drag the second project to current project's TV, do you mean into the Cakewalk GUI? Where exactly do I have to drag it to? Thanks

I know this has been raised many times before but with the promise of new features for the reborn Sonar, isn't it about time that the external insert system was given a complete overhaul? I use a lot of analogue gear on my tracks during mixdown and it's really bad that when I allocate a 'mono' port to the send, then the other half of the port is no longer available for use in a different insert. No other professional DAW has this limitation. Not sure how to start a poll on this so maybe someone could help with that? And on the topic of getting audio out of the track to feed analogue effects gear, can I also add to the wish list: 1. The ability to create an external insert with only the send configured. Why? This would allow external gear to be fed completely clean, so I mean before any other FX in the chain. It almost works at the moment. The insert send meter shows audio 'flowing' but no audio actually emerges from the allocated port. 2. The ability to store an External Insert as part of an FX Chain Preset. You can do this 'by the back door' at the moment using 'Convert FX Rack to FX Chain' but when you load this (let's say in another project), then Cakewalk refuses to play. It is clearly broken! So let's see if we can get the guys at Cakewalk to commit to a full update of the External Insert system during the first full phase of Sonar development.

On traditional audio consoles the track insert send is normally fed with audio all the time even when the insert is switched out. It is the insert return which is switched into the audio path when the insert is activated. My question is whether there is any way to get the Cakewalk external inserts to operate this way? Its really useful for checking that external gear is 'seeing' audio and checking send levels into external gear without having to make the insert 'live'.

Thanks Mark.

I have exactly the same problem that the visible/hidden status of tracks and buses is not being saved with the project. When hide a number of buses then save the project, then the buses reappear when I load the project again. I'm running the last version of CfB. I tried creating a couple of test projects and all have the same issue. Were you able to get to the bottom of this issue?

Is there any way to set the Cakewalk default so that when you create a track send it defaults to pre fader rather than post fader?

Thanks for the suggestions which are really helpful

Thanks Mark. Would you be okay to log the issue that the surface API is reporting only the stereo port friendly name when a track send is routed to a mono output, for fixing in Sonar please?

I want to derive a pre FX track send, so clean audio to send out to an analogue effects bus. Is there any way to do this without having to start duplicating tracks? I thought I could use an external insert with just the send allocated to a port but it doesn't work. All suggestions welcomed!

Thanks Mark. Would you mind please checking if it is related to a possible issue with the API which seems to be reporting only the stereo port friendly name when a track send is routed to a mono port. Many thanks.

Just found a bug on the latest early release relating to duplicate track function. If I duplicate a track which has a send routed to a mono output, then the duplicated track's send is routed to the stereo pair not to the mono send. So e.g. if I have an audio output pair with the friendly names; DAW1 : L DAW2 : R So the stereo output would show as DAW1 + DAW2 : S Let's say that track 1 has a send with destination DAW1 : L When I duplicate track 1 (to track 2), then track 2's send is to DAW1 + DAW2 : S I don't remember this error in previous releases.

Can I make another appeal for a second early access release together with an updated bug fix list so we have a final chance to check through all fixes before the final public version is released. And some idea of how long we would have to check out that second early release version before it gets frozen ready for public release.

Hi Mark Could we get an interim release to check the API fixes please?

Can I urge that another interim release is done before the public version, with an updated list of bug fixes, taking into account any work which has been done since the first early access release. Especially important if this is going to be the final release of Cakewalk by Bandlab. And maybe give us a deadline for final testing of that interim release so we don't get caught on the hop! Thanks

Thanks Mark. I'll ask Alexey to check the AZ Controller end now.

I was hoping to see an issue reported back in February dealt with in the latest update. It concerns lack of updating of the track output name in the API when a bus is renamed. Mark said he had a fix and it would be included in the next release. If you read the first three posts in the topic below, the issue and solution are discussed. Can you let me know if this is an omission will be picked up before the final release please.

Okay I found the mechanism which is triggering the change in default rec source. Please give this a try on your own system and let me know if you get the same result. The first audio input pair on my list (and so the default rec source) has the friendly name 'DEFAULT : S' For the track under test; Put the track's PAN control fully LEFT. Make sure that no source is selected to that track. Select that track's REC ARM button and the default source is selected as "DEFAULT : L" Deselect the source (back to "None") and the REC ARM button will be deselected. Now turn that track's PAN control to ANY position apart from fully LEFT. Select that track's REC ARM button and the default source is selected as "DEFAULT : S" This was 100% repeatable on any track off any project. I've reported this odd behaviour to the Bandlab guys.