Jump to content

Ronny.G

Members
  • Content Count

    37
  • Joined

  • Last visited

Community Reputation

15 Good

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi to all, I tried the new version 2021.06 Update1 to see if maybe the fixes included have solved my recent problem with track templates, however it's still present as I have reported in my previous post about 2021.06. I wanted to kindly ask if someone had a moment of time to try to perform the same operations. Insert TTS-1 (it's important that a virtual instrument is already inserted into the project) and then load a default Session Drummer 3 track template that is already included in CbB (don't matter if SS3 is installed or not, this is irrilevant, load one of it's templates only serves for the purpose of creating the input/ouput structure) as I did on video and confirm or not the problem. And it's a really weird problem. I tried everything to understand why it happens, but I couldn't figure it out. I also reinstalled from scratch the OS and CbB (of course, before I made an hard disk image). I have not installed any drivers in windows aside from the "standard" default ones that it recognized. I also left it disconnected from the network. This for have the more clean and raw system possible and eliminate any possible conflict (obviously this is only a test). Nothing, always the usual problem of wrong inputs/outputs assignments. But the most absurd thing is that, if after checking the problem, I do an hard disk partition image of the "real" pc system that has the problem, and load this one in a virtual machine inside it (with the limitations that this entails, of course) then the inputs/outputs are assigned in an correct way 1+2 - 3+4 - 5+6 ,etc, and not 7+8(TSS-1) - 1+2 - 3+4 - 5+6,etc like in the video. Really weird. The same exactly system image executed in the "real" machine generates the problem, in a virtual machine it doesn't. I don't really understand where the problem is but unfortunately I need it to work in the real machine...also I can't always keep the system in "test" mode and so for now I had to restore in the real machine the previous system image. The only thing strange that I noticed is that there is the 1st Output of Session Drummer3 named "Primary Output" and not "Session Drummer3 1" as it should, probably doesn't mean nothing however. Infact even with this name it is assigned correctly in a VM, but not in the real machine... I tried to also upload a new video with the 2021.06 update1 in action, however the forum always give me "-200 error". Many thanks to all
  2. @Milton Sica I have reported about a possible error and asked if others have the same error when performing the same operations. This is to confirm that there is actually a problem (since I can't fully isolate it considering that it occurs in a very strange way). A situation therefore completely different from what you quoted. However a little ago I also added the video of the problem, which I had not been able to upload previously. Now it is clearer what is happening. Thanks to all
  3. Solved in the last release 2021.06. Many thanks for your work!
  4. Thanks! also for pitch wheel MIDI CC conversion and track templates input/output fixes. They were my bugs reports๐Ÿ˜€ so many thanks for these two along with other improvements and fixes of the release. However, I still have a problem with fixed track templates and the new port naming. The problem its a bit weird. I have spent the last two days trying to isolate it in a reproducible manner, but it's not so easy because it seems to be dependent on the PC where CbB is installed (and not reproducible in VMs).Very strange and really I don't even understand how this could be possible, but seems so. It doesn't depend on Windows configurations, drivers installed, devices or CbB options...but the PC. I have done a lot of tests with clean hard disk bare metal images, VMs and so on excluding pretty much all. It's a bit complicated to explain all the tests I have done, so before writing a "book"๐Ÿ˜‰ for explain all and even to keep things simple...I would like to gently ask, if you have some spare time, if you could do a simple test for check this, so I could better understand if others have this strange error too. The error appears when a track template with vst multi-out is inserted in a project (kontakt or some drums VST are good examples). However I have isolated a situation in which is visible (at least for me it is) and that should be reproducible by all, without additional VSTs (all is already included in CbB) and only in some seconds of time. Try this on new project: Insert from Track Templates-Soft Synth Track Templates - Session Drummer3-LinnDrumm Tight and warm (in case it's not installed it's normal that gives you a " missing plug-in" error, ignore it and go on (ok), it doesn't matter for this test) It should load: SD3 MIDI track input Session Drummer3 (but the first couple of ports named only "primary") 1 + 2 kick input Session Drummer3 3+4 Snare input Session Drummer3 5+6 HiHat input Session Drummer3 7+8 Toms input Session Drummer3 9+10 Overheads ALL OK! Now on a new project try this: Insert the Instrument TTS-1 then add also Insert from Track Templates-Soft Synth Track Templates-Session Drummer3-LinnDrumm Tight and warm (again, in case it's not installed it's normal that gives you a " missing plug-in error, ignore it and go on (ok), it deosn''t matter for this test) It should load: input 7 + 8 TTS-1 Kick (THIS is the ERROR!) input Session Drummer3 (again the first couple of ports named only "primary") 1+2 Snare (the ports are moved by one position) input Session Drummer3 3+4 HiHat (the ports are moved by one position) input Session Drummer3 5+6 Toms (the ports are moved by one position) input Session Drummer3 7+8 Overheads (the ports are moved by one position) It happens also to you? You have to correct all the inputs stereo couples because by mistake it inserts the last one (in this example 7+8 of TTS1) of the VST instrument loaded first and then it moves all subsequent inputs stereo couples. I upload also a small video of the problem. I hope it's clear. Many thanks to all for your help!
  5. Hi, I would like to report a possible bug in the "convert MIDI continuous controller (CC) events to/from automation envelopes" function which occurs when values come from pitch wheel (Wheel). I did not remember that the conversion function was only introduced for the first time in version 2021.04 and so I posted the message in the general section of the forum. In order to avoid a double post, I report in this specific thread only the link to my message related to this possible bug, message in which I also attached two short demo videos. Many thanks to everyone
  6. Thanks for the suggestion. In fact I seemed to remember, but I was wrong, that this new conversion feature was introduced in a version before 2021.04, instead in fact it was introduced for the first time only in the latest release 2021.04. Maybe in case it will be not noticed I will make a further report in the thread of 2021.04. Thank you Posting in the thread of the "early" 2021.06, from what indicated, would be not entirely appropriate, since in that thread you have to report only specific problems of the "early" version and not of other versions. This bug is not specific to the early preview 2021.06 since it was already present in the previous one...
  7. Thanks for fixing this issue I reported Many thanks for your work to make CbB better and better!
  8. Hi to all, Yesterday I noticed a bug in the midi CC to/from automation envelopes conversion function that I would like to report. I tried both in the last release 2021.04 and in the latest "early" 2021.06. If the values are of pitch wheel type, there are two distinct (or maybe there's a connection between the two, I don't know...) bugs depending on whether the transformation is performed from envelope to MIDI CC or from MIDI CC to envelope. 1) Automation envelope to MIDI CC: There is probably an error with ( + / - ) in the code of the conversion function because the result is this strange curve. 2) Midi CC to envelope: The peak value never reaches the maximum (+8192) in this case but there is a strange "beveling" on the tip. With other type of midi CC's the conversion function is correct. It's the pitch wheel values that generate problems, probably for the -8192 / + 8192 range of values. I hope that this bug report can be useful in finding the error. It seems to occur only in the presence of values of type pitch wheel in this very useful conversion function that has been recently introduced. The addition of this conversion function has actually proved a lot for me. Be able to visually work with the CC values directly under the midi track (using all the shaping functions available for envelopes) while still retaining the possibility of convert them to the piano roll view. Really useful! Many thanks to all
  9. Hi, the problem seems solved to me in the last beta release. I have run some test and now the midi routing is saved correctly in the track template. Thanks again for your work on this!
  10. @msmcleod I am very happy with the news!๐Ÿ˜ƒ Thanks to the entire development team for taking care of the bug. For now, as you write, I will no longer use the track template function at all just to be sure ๐Ÿ˜‰ so as to wait for the release of the fix and see if the problem is solved. I will report here. Then I will start create again new templates, just to be sure to not mix for error those that have midi routing with the "normal" ones, starting from scratch. Many thanks again for your and the entire development team, interest and work on fix this annoying bug
  11. 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
  12. Hi to all and thanks for your replies. 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. 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.
  13. 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!
  14. 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.
  15. You could introduce an option to disable this behavior introduced with the last update and return, if desired, as it was before? There are cases where for speed or convenience it's easier to act for example on modulation and pitch wheels or even other particular controls of the VST synth that are exposed as midi out directly acting on the wheels, buttons or other within this and record them as midi events, without necessarily having them assigned to an external MIDI controller or create an additional MIDI track (useless) in CbB just to get around the limitation of not being able to activate the VST midi output on their own inputs and record these, as it was possible before the change. Many thanks you for your support
ร—
ร—
  • Create New...