Ronny.G Posted April 30, 2021 Share Posted April 30, 2021 Hi to all, I would like to report a bug. The bug is related to midi input routing save. As you know, this is a problem that has been present for years, I have noticed in fact that users over time have repeatedly highlighted the problem in different forms and conditions. I don't know why it is still present, I think that when you route some virtual synth it is important to not have to redone again the routing work everytime (...when you can...in many cases you have to delete and load again all the virtual synths because it is impossible to delete anymore the "wrong" midi inputs added) There have been several attempts to explain the problem (modification in connected midi devices of the active device type at the time of saving and later not connected at the time of reopening the project or connected to a different USB port) or to at least limit the bug. But in reality unfortunately the bug does not depend only on the connected peripherals or not...it seems most related with virtual synth input ports. I was hoping that with the last early update, since a change had been inserted in the management of the midi ports of virtual synths, had been fixed but unfortunately this was not the case. I tried through this short video to highlight the center of the bug by simplifying it. In fact, the situation is much worse. In fact, the more complex the midi routing, the more the problem arises, with the usual randomly modified midi inputs (double, triple, all active, none...). In several cases it is not even possible to correct the problem of inputs that always remain active and you have to delete all the uploaded virtual synths and start from scratch, thus doing all the configuration again! For some it simply shows up after saving and reopening the project. In my case if the file is saved and then reopened the input midi channel assignments "seem" to be correct. But I would say that it is only luck, because every now and then the bug also occurs to me as to many others even just reopening a previously saved project. Actually as this video highlights, the bug occurs regardless of the subsequent closure and reopening of CbB under different conditions. Instead if I save the input settings of the various synths such as track settings, delete the tracks and restore the track settings save (without obviously closing CbB) the bug instantly appears as you can see. Unfortunately, this bug has been and remains somewhat annoying. You waste a lot of time reopening or editing tracks to reconfigure everything! I would therefore kindly like to ask you whether you can check what the problem is and solve it once and for all. I am sure that would certainly make so many users happy as the bug has been present for years. From my point of view, routing and managing audio and midi tracks (in this case) is a major feature in a DAW. It is the basis from which to carry out any work. It has to work and certainly once a template is configured the routing (sometimes it can also be quite complex with the various VSTs) should stay. If every time the saves made are not kept and everything has to be redone it becomes... Many thanks for your work and time Ronny 1 Link to comment Share on other sites More sharing options...
Glenn Stanton Posted April 30, 2021 Share Posted April 30, 2021 just curious - this happens if you delete the track - settings get lost, then a new track to the virtual synth does not then re-establish the settings? or a crtl-z (undo) after deleting a track does not restore the settings? Link to comment Share on other sites More sharing options...
chris.r Posted April 30, 2021 Share Posted April 30, 2021 Happened to me in the past. It resulted in a huge mess to the point I had to reload synths from the scratch. Also I recall Cakewalk somehow managed to swap two physical outputs in a project or template, don't remember exactly. I had two physical devices connected to my Pc, one on the Master bus and another on a send bus, and with time, while disconnecting one of them occasionally for no use, I did end up with the two being swapped permanently and had to reassign it again. How? Link to comment Share on other sites More sharing options...
Matthew Sorrels Posted April 30, 2021 Share Posted April 30, 2021 It looks like your using simple instrument tracks and assigning their outputs to the inputs of other simple instrument tracks. Then saving and loading a track template of a group of them (which isn't the same thing as loading/saving a project). I almost never use the simple instrument tracks, which might explain why I've never seen these reassignment issues. And I'm not surprised that track templates can't restore the MIDI routing correctly to be honest, when the routing involves other simple instruments. Does this happen if you split everything into separate audio and midi tracks? It might be useful if you were to write the exact steps to reproduce the bug(s) as text, it's very hard to follow the animated GIF. You should also list/name the synths you are using (and if they are VST2 or VST3). Those kinds of details can be very important. If you can create a 100% reproducible set of steps, the odds Cakewalk will be able to fix it goes up a lot. In this case I think you have a lot of factors including simple instrument tracks, track templates, and synths with outputs. Each part of that mix has been know to have issues for one reason or another. Combining them all together I'm not completely surprised it doesn't work right. Yes I know that doesn't help much. This specific issue you are showing also may not be related to your overall issue either (of MIDI routing being lost in projects) this might just be one of dozens of situations where the routing can be lost. 1 Link to comment Share on other sites More sharing options...
John Vere Posted April 30, 2021 Share Posted April 30, 2021 Simple instruments tracks have many pitfalls. This just came up yesterday where if you freeze a simple instrument track and it becomes stuck you loose the synth and your midi data. I have always used a midi track and I have never had routing issues for this reason. If I need to compress my tracks I use folders. My default track templates have folders for drums, piano and strings. Link to comment Share on other sites More sharing options...
Matthew Sorrels Posted April 30, 2021 Share Posted April 30, 2021 Using NoteMapper, RandARP and FM8 (I don't have Dexed installed but I don't think it actually matters what the final audio synth is) I was able to reproduce your bug. The inter-track midi routing is lost when loading the track template. In case Cakewalk needs them those MIDI generating synths are all freely available on the net. 1 1 Link to comment Share on other sites More sharing options...
Ronny.G Posted April 30, 2021 Author Share Posted April 30, 2021 (edited) 7 hours ago, Glenn Stanton said: just curious - this happens if you delete the track - settings get lost, then a new track to the virtual synth does not then re-establish the settings? or a crtl-z (undo) after deleting a track does not restore the settings? It happens if I save them as a track template when I open again the track template saved to restore it with its assigned midi input and output. 7 hours ago, chris.r said: Happened to me in the past. It resulted in a huge mess to the point I had to reload synths from the scratch. Also I recall Cakewalk somehow managed to swap two physical outputs in a project or template, don't remember exactly. I had two physical devices connected to my Pc, one on the Master bus and another on a send bus, and with time, while disconnecting one of them occasionally for no use, I did end up with the two being swapped permanently and had to reassign it again. How? This could be a related problem. In this case, from what I understanded, it should happen because every time CbB it’s started it assigns a “number” to connected external midi devices that recognizes, if one was connected when you saved the project but the moment you reopen CbB and the project is not connected, this could give problems. For example the midi device “”number 2” become “number 1” because your “number 1” device isn’t connected and that's already in itself a problem. Add to this that even if the USB devices are both connected you should always check that they are connected to exactly the same port in the pc 6 hours ago, Matthew Sorrels said: It looks like your using simple instrument tracks and assigning their outputs to the inputs of other simple instrument tracks. Then saving and loading a track template of a group of them (which isn't the same thing as loading/saving a project). I almost never use the simple instrument tracks, which might explain why I've never seen these reassignment issues. And I'm not surprised that track templates can't restore the MIDI routing correctly to be honest, when the routing involves other simple instruments. Does this happen if you split everything into separate audio and midi tracks? It might be useful if you were to write the exact steps to reproduce the bug(s) as text, it's very hard to follow the animated GIF. You should also list/name the synths you are using (and if they are VST2 or VST3). Those kinds of details can be very important. If you can create a 100% reproducible set of steps, the odds Cakewalk will be able to fix it goes up a lot. In this case I think you have a lot of factors including simple instrument tracks, track templates, and synths with outputs. Each part of that mix has been know to have issues for one reason or another. Combining them all together I'm not completely surprised it doesn't work right. Yes I know that doesn't help much. This specific issue you are showing also may not be related to your overall issue either (of MIDI routing being lost in projects) this might just be one of dozens of situations where the routing can be lost. I thought so too, unfortunately it happens also if I don’t use simple instruments tracks and I insert separate audio/midi tracks and then I set up them as needed. Same problem. I've made several attempts, simple instruments, manually, starting from the synth rack… 6 hours ago, John Vere said: Simple instruments tracks have many pitfalls. This just came up yesterday where if you freeze a simple instrument track and it becomes stuck you loose the synth and your midi data. I have always used a midi track and I have never had routing issues for this reason. If I need to compress my tracks I use folders. My default track templates have folders for drums, piano and strings. I can also create and save templates like yours and they works but have you done some internal midi routing between them as for example I showed in the animated gif, saved and restored the template? It's a different thing. If you only assign the various VST instruments to the tracks and save a template for later, it works. The problem is the saved internal routing of virtual instruments midi input and output between the tracks that is not kept. 6 hours ago, Matthew Sorrels said: Using NoteMapper, RandARP and FM8 (I don't have Dexed installed but I don't think it actually matters what the final audio synth is) I was able to reproduce your bug. The inter-track midi routing is lost when loading the track template. In case Cakewalk needs them those MIDI generating synths are all freely available on the net. Thank you very much for finding time to give it a try! Really appreciate It doesn't matter which plugin you use. If you see I also inserted a virtual "external MIDI device" as primary input device, precisely because doing so this variable is also eliminated. I could connect a USB keyboard or any other external physical MIDI device and nothing changes. The problem there's anyway. In fact, I noticed the problem because I was trying to set up a physical external MIDI device with CbB... And if you have done some tests you have noticed that it is even worse, try to change the ports that have been incorrectly enabled when the bug screwed them and you get out crazy, they reappear even after you remove them. You have to delete all the VST and restart. I chose to use these in my example because being small and freeware allow everyone and maybe the support team to quickly do reproducible experiments similar to what I (and now you…) have done. I didn't even notice any differences between VST2 or 3 or a mix between the two. Auto Echo On or off in CbB settings.The problem always arises. Maybe in a slightly different way. Because as others have pointed out in the past it comes in slightly different forms but I think the basic problem is always the same What could be interesting will be if the virtual midi ports exposed by the various VST instruments (after obviously enabling the midi output on them) could be saved as “midi input presets” like it is possible now for the external ones (physical or virtual). However CbB at the moment doesn’t allow this. I hope that the CbB developer team can do something to fix this bug. There are many VST's that now generate outgoing midi signals for the most diverse purposes, notes, arpeggiators, midi converters and filters and generators of all kinds, and you should be able to save a template with the configuration you need. Which is actually what the track template should allow if there wasn't this bug. Many thanks to all of you for your interest in this problem.Greetz Ronnie Edited April 30, 2021 by Ronny.G Link to comment Share on other sites More sharing options...
chris.r Posted April 30, 2021 Share Posted April 30, 2021 22 minutes ago, Ronny.G said: every time CbB it’s started it assigns a “number” to connected external midi devices that recognizes, if one was connected when you saved the project but the moment you reopen CbB and the project is not connected, this could give problems. For example the midi device “”number 2” become “number 1” because your “number 1” device isn’t connected... That, I would call a design flaw, rather than bug. I mean, in Windows, is an app not being able to distinguish perfectly between different devices connected? I thought each device has its unique signature number or something. If so, then it should be easy for the DAW to assign an internal number for each respectively... and not mess with the numbers later on. 1 Link to comment Share on other sites More sharing options...
bvideo Posted May 1, 2021 Share Posted May 1, 2021 8 hours ago, chris.r said: That, I would call a design flaw, rather than bug. I mean, in Windows, is an app not being able to distinguish perfectly between different devices connected? I thought each device has its unique signature number or something. If so, then it should be easy for the DAW to assign an internal number for each respectively... and not mess with the numbers later on. For USB devices, the establishment of uniqueness depends on the type of device. Disks and many other device types have unique identifiers down to the serial number of the individual device. Unfortunately, the USB MIDI class was defined without a serial number, just vendor ID and product ID. So two devices of the same make and model are not distinguishable. Can they be distinguished by which hub and port they are plugged in? Maybe, so don't ever shuffle them. Do Cakewalk and Windows do everything that could be done to uniquely identify devices, I'm not sure. But it's definitely an imperfect situation in the USB MIDI specs. 1 Link to comment Share on other sites More sharing options...
Ronny.G Posted May 1, 2021 Author Share Posted May 1, 2021 (edited) 19 hours ago, chris.r said: That, I would call a design flaw, rather than bug. I mean, in Windows, is an app not being able to distinguish perfectly between different devices connected? I thought each device has its unique signature number or something. If so, then it should be easy for the DAW to assign an internal number for each respectively... and not mess with the numbers later on. I totally agree with what you say. I also don't always have all the external MIDI peripherals turned on when I edit a project and so also happen to me every now and then to have to reassign correctly the external peripherals and it's annoying. Maybe something could be done about this, too. If technically possible (there are probably also the limitations related to windows and USB specs, as bvideo explained (thanks) but there should be a way to manage the presence or not of a connected external device during the following project saves without having problems. Perhaps also add an alert when the project is opened again to highlight the lack of the device and ask or suggest a reassignment (perhaps taking advantage of the MIDI custom names already present in CbB). But a specific post should be opened about this, probably some connection between these problems could exist, since they always concern the management and saving of MIDI inputs and outputs (physical and virtual) by CbB but I highlighted a different problem in this post. The bug that I have reported here in this post already happens when CbB program it's open and therefore without connecting or disconnecting something (or changing USB port on pc). I really hope that the development team can understand the problem and fix it because it's very annoying. It already takes time to properly config track templates that are useful. It is obviously hoped that in doing so it will save time later by recalling them, but at the moment in the conditions I have highlighted this is not possible. Edited May 1, 2021 by Ronny.G 1 Link to comment Share on other sites More sharing options...
msmcleod Posted May 1, 2021 Share Posted May 1, 2021 On 4/30/2021 at 8:57 PM, chris.r said: That, I would call a design flaw, rather than bug. I mean, in Windows, is an app not being able to distinguish perfectly between different devices connected? I thought each device has its unique signature number or something. If so, then it should be easy for the DAW to assign an internal number for each respectively... and not mess with the numbers later on. I took a look at this earlier on - it is a bug. While its true that in Windows there isn't any way of truly distinguishing between hardware MIDI ports (although Cakewalk does try its best to get around this by also using the device name), this is not what is happening in this case. The issue is that it's losing the internal MIDI device ID of the soft synth when loading the template. It then gets that mixed up with the real hardware device ID. Disabling the MIDI output of synths that you don't need MIDI output for will go some way to mitigate this issue. 1 Link to comment Share on other sites More sharing options...
Noel Borthwick Posted May 2, 2021 Share Posted May 2, 2021 We’ll try and reproduce it thanks. BTW hardware MIDI ports dont have a unique signature in Windows so shuffling devices around lead to tracks getting assigned to different devices. They are just indexed hence its difficult to identify when devices are added and removed. There is really no easy way to get around this. We’ll look into your specific case and see if something can be done with templates. Also if you haven’t changed anything with your configuration the ports shouldn’t change. Link to comment Share on other sites More sharing options...
Ronny.G Posted May 2, 2021 Author Share Posted May 2, 2021 (edited) 19 hours ago, msmcleod said: I took a look at this earlier on - it is a bug. 5 hours ago, Noel Borthwick said: We’ll try and reproduce it thanks. We’ll look into your specific case and see if something can be done with templates. Also if you haven’t changed anything with your configuration the ports shouldn’t change. Thank you! The problem with track templates as I have highlighted arises without changing anything. It already occurs with the CbB open, saving the desired configuration as a template, deleting everything and reload the newly saved template. I would also like to take this opportunity to point out a message that I wrote in the feedback specific thread for the last 2021.04 update, because it concerns the management of midi inputs and outputs of virtual instruments. The latest update introduced a change in the UI "MIDI Ports from synths should not be exposed to their own inputs". This is certainly useful in many cases but it can also be a limitation in others and so I asked there, explaining the reasons, if it was possible to have a selection option somewhere to make a choice about it. Thank again to everyone, users and support team for your help and work. Edited May 2, 2021 by Ronny.G Link to comment Share on other sites More sharing options...
chris.r Posted May 2, 2021 Share Posted May 2, 2021 (edited) 18 hours ago, msmcleod said: I took a look at this earlier on - it is a bug. While its true that in Windows there isn't any way of truly distinguishing between hardware MIDI ports (although Cakewalk does try its best to get around this by also using the device name), this is not what is happening in this case. The issue is that it's losing the internal MIDI device ID of the soft synth when loading the template. It then gets that mixed up with the real hardware device ID... Thanks for confirming. In my post I was relating more to a hypothetical situation where Cakewalk would hiddenly replace an audio device's outputs with another when the previous is not plugged in, as described here: On 4/30/2021 at 8:19 PM, Ronny.G said: In this case, from what I understanded, it should happen because every time CbB it’s started it assigns a “number” to connected external midi devices that recognizes, if one was connected when you saved the project but the moment you reopen CbB and the project is not connected, this could give problems. For example the midi device “”number 2” become “number 1” because your “number 1” device isn’t connected and that's already in itself a problem... something similar, only with audio devices, happened to me in the past. Unfortunately it took me by surprise and I didn't check the conditions that led to it. But Ronny's right I should open a separate topic. Anyway glad to see MIDI routing issues are being nailed. EDIT: actually I created a thread but it didn't help much. Edited May 2, 2021 by chris.r Link to comment Share on other sites More sharing options...
Ronny.G Posted June 6, 2021 Author Share Posted June 6, 2021 I would rather report that the bug is still present in the latest release 175. It's really annoying since it makes practically impossible to save specific track templates with MIDI routing configurations between virtual instruments. Among other things in some cases I could not even reuse the saving of the entire project because in a couple of cases even this once reopened had lost the routing set (and I had not modified anything connected to the pc). However, returning to the track templates and the bug, without being able to have a working (and reusable) midi routing between various VST, you can not "create" a reausable chain to be able to modify or alter the input MIDI data with numerous plugins whose purpose is to alter the input MIDI data (arpeggiators, CC modifiers, curves, note substitutions, etc). Without being able to save anything, it's necessary every time to recreate all the route...maybe if you have a couple of tracks it will be feasible but when there are numerous tracks it's impractical to recreate the whole configuration in the project from scratch every time. I really hope this bug is fixable as soon as possible. At the moment many times I'm forced to give up the use of CbB (with great regret...) precisely because of this annoying bug. Although the bug has already been confirmed and we are waiting for a solution I invite anyone who has a moment of time and wants to try to perform also some tests to realize the problem. I obviously take the opportunity to thank everyone who works every day to make CbB a more complete and wonderful product (articulation maps and arranger have been great additions). THANK YOU! Link to comment Share on other sites More sharing options...
Starship Krupa Posted June 6, 2021 Share Posted June 6, 2021 Thanks for pinning this down, @Ronny.G. I think this is the "sacrifice a chicken" bug that has bedeviled me since adopting Cakewalk. I called it that because of all the different weird steps that it took to get MIDI working again once the soft synth or effect stopped listening. I use nothing but split instrument tracks, which seemed to cool it down somewhat, but I like to experiment with replacing synths, and that sometimes results in the need for chicken sacrifice: close and reopen the project, if that doesn't work, replace the synth a couple of times, if that doesn't work, delete the entire synth track and create it again, if that doesn't work, copy the MIDI track and delete the old one, and so on until you get to the "nuke the site from orbit" step of exporting everything as audio or MIDI files and starting with a brand new project. The trouble is, I could never figure out the exact steps that led to the failure mode, so I couldn't submit it as a bug. It just worked until it didn't. 1 Link to comment Share on other sites More sharing options...
Elena Kolpakova Posted June 7, 2021 Share Posted June 7, 2021 Hey there, sorry for intruding in this thread, but since I've also experienced multiple MIDI ports being selected in the past, I thought it'd be good to have all of them collected in one place and fixed. Most likely all of them are related to the same root cause. But if it's not OK, please let me know and I'll distribute them to other topics. Scenario 1 Unplug your USB MIDI keyboard from the computer (I'm using NI KK S88 MK1). Launch Cakewalk. Start a blank project. Create an Instrument track using any synths (whether "Enable MIDI Out" option is ticked or not doesn't matter for this scenario). Note that by default MIDI In is set to Omni for this track. Arm the track for recording (I don't have auto-arm enabled for MIDI tracks in Preferences). Note that MIDI In port is changed to "All Inputs" (or "All External Inputs" if "Enable MIDI Out" option was ticked at step 4). Plug in your USB MIDI keyboard. Wait for the popup asking if you want to enable the newly connected MIDI device and press "Yes". Click the "MIDI In" dropdown on the track to see what is now selected. Expected to observe: "All Inputs" (or "All External Inputs") entry is still selected. New ports related to the USB keyboard should be present in the list but not marked as selected. Actually observed: "All Inputs" (or "All External Inputs") entry is no longer selected. "All Inputs" - should be selected. All other MIDI ports available to the system before the USB keyboard got connected are now selected with checkmarks. "Maschine MK3 Ctrl In" - should not be selected. "Virtual Controller" should not be selected. New ports related to the USB keyboard are present in the list and are not marked as selected. Scenario 2 (partly fixed by 2021.04 Build 175) - related to "MIDI Ports from synths should not be exposed to their own inputs." Originally (prior to 2021.04), the reproduction scenario was the following: Plug in NI KK keyboard. Launch Cakewalk. Make sure all MIDI In devices related to KK keyboard are checked under MIDI Devices tab in the Preferences (at least "Komplete Kontrol In - 1" and "Komplete Kontrol DAW In - 1". Start a blank project. Create an Instrument track using Komplete Kontrol VSTi with "Enable MIDI Out" option ticked. Note that by default MIDI In is set to Omni for this track. Arm the track for recording (I don't have auto-arm enabled for MIDI tracks in Preferences). Start recording. Play some notes on the keyboard (actually play just one note once to simplify the whole thing). Stop recording. Click the "MIDI In" dropdown on the track to see what is now selected. Open the Event List and note how many notes are present now? Prior to 2021.04 you would observe the following: After step 11, three ports are marked as selected: "Komplete Kontrol In - 1" - HW port 1 "Komplete Kontrol DAW In - 1" - HW port 2 "Komplete Kontrol 1" - SW port from "Enable MIDI out" feature After step 12, as expected, you'd get two notes instead of one (with the second note coming after a short delay equal to your full system latency. The duplication kinda makes sense: The pressed key arrives as MIDI event from HW port 1, It is recorded as a note for the first time. It is then passed to KK VSTi. KK VSTi plays it through to its virtual MIDI Out. And it is then picked up and recorded for the 2nd time via the SW port from "Enable MIDI out" feature. I once described it briefly here: Now, 2021.04 is supposed to address this feature as "MIDI Ports from synths should not be exposed to their own inputs." However the following is observed instead: After step 11, only one port is selected: "All External Inputs" After step 12, I still have two notes recorded! This shouldn't happen as the 2nd note coming from "Komplete Kontrol 1" shouldn't have made it to the recording, but it did. There's a way to "fix" this: Select "None" as MIDI In for the track Now reselect "All External Inputs" again If you now repeat steps 8-10, only one note will be recorded So it looks like for an Instrument track which has "Omni" set as its MIDI input, "Arming a MIDI track + Recording a track" changes the MIDI In port to "All External Inputs" not properly. Only manually selecting "All External Inputs" does the trick. 1 Link to comment Share on other sites More sharing options...
Ronny.G Posted June 7, 2021 Author Share Posted June 7, 2021 (edited) Hi to all and thanks for your replies. 19 hours ago, Starship Krupa said: The trouble is, I could never figure out the exact steps that led to the failure mode, so I couldn't submit it as a bug. It just worked until it didn't. The small video I uploaded allows you to recreate the bug if you perform the same steps as shown. So there is a way to recreate always the bug, at least in this case. This was also confirmed by others who kindly performed the same test. Unfortunately from what I understand there are two "macro versions" of this problem with MIDI inputs. The first "version" concerns external MIDI peripherals connected to the system at the time of saving the project. This trouble also depends on how Windows handles USB peripherals. If the connection order is subsequently changed for some reason (e.g. the physical port to which the MIDI device its connected is changed, or isn't connected at all ) this confuses CbB that it is not able to assign the same "numbers" to the MIDI connected devices again. The second " version" the one I indicated in this thread concerns instead the "virtual" MIDI peripherals (example VST) that are inserted in the project. These can also have MIDI inputs and outputs like physical peripherals. Unfortunately when you save a track template after configuring routing with virtual synths that have MIDI inputs and outputs, this is not maintained once you reload the saved track template. And this is a CbB bug. It does not depend on external factors since it occurs with CbB open, without changing anything in the connections of any external devices that could affect the "virtual" ones. However I think it's clearly visible from the small video of the bug I posted. 14 hours ago, Helene Kolpakova said: Hey there, sorry for intruding in this thread, but since I've also experienced multiple MIDI ports being selected in the past, I thought it'd be good to have all of them collected in one place and fixed. Most likely all of them are related to the same root cause. But if it's not OK, please let me know and I'll distribute them to other topics. I read your interesting and detailed post (many thanks), hard to tell if there is a link or not with what I reported. It is probably the management of MIDI inputs and outputs by CbB that should be checked in general because there are several problems. However, my message only concerns a bug in the presence of VST instruments and track templates so it is limited to a specific problem. It seems to me your case falls more into the first "version" of the problem and then it's about the link order (or lack of these...) of external physical MIDI peripherals that were connected at the time of saving. Unfortunately I also have regulary the same problem reported by you. As a small tip, Since from what I've seen it looks like you only have external peripherals, you tried saving your inputs using "presets" and "Manage presets" in the INPUT menu and then calling up and using these saved presets to manage external peripherals instead of selecting them directly in the menu? You can create presets for MIDI inputs "external" and from what I noticed it seems that in this way you can in many cases bypass the problem. If you have time, give it a try. Edited June 7, 2021 by Ronny.G 1 Link to comment Share on other sites More sharing options...
Ronny.G Posted June 13, 2021 Author Share Posted June 13, 2021 (edited) Unfortunately today the bug has also manifested itself with CbB and a project opened. So it can also occur under these conditions unfortunately. I was doing some tests on a project using virtual synths. With a project opened at some point I lost the sound coming from a plugin with a previously working midi routing properly set. I checked then to understand the cause and the midi inputs were suddenly all wrong! Probably when I loaded an additional virtual synth (and enabled its midi output) in the project, by mistake, CbB also modified the other MIDI inputs previously set on other tracks. Unfortunately, as usually happens when the bug occurs, it was impossible to manually change the midi inputs set in the individual tracks for MIDI routing and restore the pre-existing situation. Once in fact this bug occurs, it seems that CbB no longer allows any changes to the MIDI inputs in the tracks, and therefore despite trying to reset the correct midi inputs these are no longer accepted (or at the limit even if accepted, in fact, checking immediately after, you find yourself with random settings...). I had no choice but to trash the project and start all over again, trying to transfer all the changes already made in the tracks (synths, midi routing, aux, bus, sidechain, etc.) in addition to the MIDI recordings already made. What a waste of time...and even worse, just when I had had a couple of ideas and was trying to record them... Almost certainly it's always the same bug that occurs in various situations. It's not about "external" MIDI peripherals (even with these there is a problem, but it is caused by a different problem from what I understand) but it concerns the enumeration and management of midi inputs and outputs of virtual instruments by CbB. In different situations they are not maintained (now I know...even with open program and project). Obviously if this bug creates problems also to you, please post your experiences and maybe even some small videos, so that they can also be of help to the developers to better understand and solve this bug. I don't think I'm doing any particular operation, I'm just trying to insert and manage virtual instruments that also have midi outputs to insert into other virtual instruments. I hope I'm not the only one who gets into trouble with this bug. I think it should also cause problems for many others. Without making a precise list of the many synths that have MIDI outputs. there 's plenty of them. Strange that there are not many reports, probably a different workflow. Thanks to everyone Edited June 13, 2021 by Ronny.G Link to comment Share on other sites More sharing options...
msmcleod Posted June 13, 2021 Share Posted June 13, 2021 @Ronny.G - We've fixed the issue with templates that you reported in your first post. This will be available in the next release. Your latest issue sounds like it could be different, but it could also be related to the original bug... did you load any track templates in this project? The original bug means that the MIDI ports are in a strange state after importing the template. This might explain why you cant change the ports after importing. For the moment, I'd advise against loading/saving synth templates with routing until the next release. Routing from hardware MIDI ports should be fine, but if the template contains MIDI routing from synths within the template, that's where the issue arises, and it pretty much messes up all the ports. Like I said though, it's been fixed for the next release. 2 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now