Jump to content

Paul DeRocco

Members
  • Content Count

    36
  • Joined

  • Last visited

Everything posted by Paul DeRocco

  1. The "MIDI interface" is the external keyboard that is playing the sequence, which has a USB device port. There is no 31250bps serial MIDI here. And there is no bulk data involved here, either.
  2. (Latest Cakewalk, Win7, pure MIDI sequence on external synth) I have an NRPN in my sequence, which I can see in Event List, but it's not getting to my synth. I redirected that track through loopMIDI into MIDI-OX, and I can see all the messages except this particular one. Is there any setting anywhere in Cakewalk that could cause an NRPN to be filtered from the output?
  3. This problem keeps cropping up, and then going away. I've successfully used Cakewalk (always current version) to create MIDI sequences, play them on an external instrument, and record the audio that comes back in order to create a final audio file. But frequently, the MIDI sequence plays at the wrong speed. At the moment, I have a sequence that reliably plays about 2.8% slow, so the 128-bar 4/4 112bpm song which should take about 4:34.3 ends up taking about 4:42. While capturing the audio, it displays nicely in the audio track directly below the MIDI, and I can see the amplitude bumps lining up with the MIDI above it. When I stop recording, it redraws the audio at its real size, which is substantially longer than the MIDI. But since it only allocated enough space in the track for 128 beats, the end of the song is lost. I've also had the MIDI suddenly start to play reallllly slow, like 40% to 60% of nominal speed, at a particular point in the sequence. And no, there is no tempo track data on this sequence, this is 112bpm from start to finish. And this has happened in other sequences, too. So what the heck is Cakewalk using for its timing reference when it spits out MIDI to an external instrument? Since I record 48K digital audio from the instrument, I would think that would make a perfectly good timebase. And why would it do this intermittently? Is there some option I have to set somewhere? BTW, I'm using the standard Windows USB MIDI driver to communicate with the instrument. I've also tried forcing it to use another driver, from Korg, even though it's not a Korg instrument, and that produces identical results. So it doesn't appear that it's an issue with the specific MIDI driver. Internally, it's using MME to talk to the driver, since that's the only choice. Added info: I've verified that when only playing (or recording) MIDI, it runs at the correct speed, and when playing MIDI and recording the digital audio that comes back, it runs slow. I found an option under Audio Driver Settings for Playback Timing Master and Record Timing Master, and they are both set to the only choice, which is my digital audio input. I know for certain that my instrument input is exactly 48KHz, because its analog output is in tune, and when the digital output is properly recorded and played back through the analog output on my desktop machine, it is still in tune and takes the exact amount of time it should. It's behaving as though when merely playing the MIDI sequence, it uses some internal timebase despite the Audio Driver Settings, but then when playing MIDI and recording the digital audio that comes back, it is trying to sync to the audio sample rate and simply getting it wrong, which would mean it's a bug in Cakewalk.
  4. @Heinz Hupfer I have 2020.01 build 28, 64-bit. The only backgrounds that are colored are in the track pane (at least the way my screen is configured, which is pretty close to the default screenset 5), and they light up when that checkbox is checked. I would expect that "Show strip colors" would show some colors somewhere when it's turned on, not when it's turned off.
  5. I found the problem. Since all I wanted to use the audio for was to record the result of playing a MIDI sequence on an external synth, and then export it as an audio file, I hadn't selected an audio output device. Apparently, Cakewalk won't record audio input if you haven't selected an audio output, even if you're not using it.
  6. Thanks for the advice. I found the combo that works. If I select a track color in the inspector, it overrides the default for the note foreground color. But it also changes the background color for the inspector and the track controls, which is garish and distracting. But if I turn off the "Show strip colors" option in Edit->Preferences->Customization->Colors, then I only see the color on the notes, and in a little stripe to the left of the track controls, which is fine.
  7. When I create a new MIDI track, I get a different color for the notes in the track, and in PRV. If I duplicate a track, then I get the same color. I often create a new track by duplicating an existing one. Is there a way to change the colors of all the notes in a particular track? Edit->Preferences->Customization->Colors->MIDI Tracks shows a bunch of track colors based on the last digit of the track number. Fiddling with them changes the palette of colors, but doesn't change which palette entries each track refers to. I'd be satisified if I could just reset the tracks to the colors they should normally have based on their track numbers.
  8. Ahh, that's the problem. I forgot that I was using audio for the metronome. Fortunately, I only need that when recording the first track; after that, I can turn it off, so that's not a real problem. Thanks.
  9. I'm doing MIDI sequencing with external keyboards and synths. There are no audio tracks, and no audio output from Cakewalk. I keep having to turn off the audio in Cakewalk in order to use other audio apps, and then when I return to Cakewalk to play a sequence, it steals the audio back. How do I set up the project so that it doesn't try to open an audio output, and therefore prevent other apps from using that output?
  10. Well, I hope someone on the Cakewalk team at BandLab notices this discussion.
  11. Nice piece, David. I think those are the kind of tempo changes that Fit Improv might screw up on. I've attached two small projects, one before and one after, that demonstrates the problem. (They're the same sequence I posted in that other thread.) There's some stuff that appears right after 7:02 in the before, and ends up on 6:01 in the after. You can see that the proportions of the notes are way out of whack. In the after, the three upper notes at 6:01 are now shorter than the released period of the Sustain. Also, the notes before 6:01 extend almost up to 6:01, while the same notes in the before end much earlier. You don't notice too much of a difference because the actual durations are determined by the Sustain, but at that point, and at a few others in the full sequence, it matters. It really does look like the programmer did it the "dumb" way, recalculating the note duration based purely on the tempo at the start of the note. But the version you posted in the other thread that you did with Set Measure/Beat At Now doesn't have this problem, so it's obviously not using the same algorithm. I guess I'll just have to use SM/BAN until (if) they fix this bug. FitImprovTest.zip
  12. I just used Fit Improvisation on a piece that had lots of rubato playing and long pauses. It basically works, but it doesn't recompute the note durations properly. I suspect it adjusts the duration based on the new tempo at the start of the note, but if the note is long and the tempo changes in the meantime, it ends at the wrong time. I found several spots in my song where the end of the note wound up on the wrong side of a Sustain Switch On control. Having to go carefully through the entire piece to find notes that are either chopped off early or that hang on way too long is tedious. I haven't tried Set Measure/Beat At Now yet, but I expect it has the same problem. The only solution is to keep track of which notes are still on, and keep adjusting their durations whenever a new tempo is generated or encountered. It's not trivial, but it's important.
  13. Excellent! Thanks so much for noticing that. I had created four notes, then cut and pasted them in each measure, adjusting their positions, rather than drawing each beat from scratch. In that one measure I must have bounced on the Ctrl-V. It would be nice if the program popped up an error message saying where and why it stopped. I looked at SMBAN, and it looks pretty good, except that it defaults to the nearest next beat, which isn't always correct, so you have to type in the right number rather than slide the note in the PRV. But I may try it out on another song. I found a flaw in Fit Improv, though, which I'm reporting in a separate post.
  14. No, there are none. It would be really obvious if it had done anything, even if it only took a millisecond: all the notes would have moved so that they're aligned with the bars and beats. I've attached a short project containing an eight bar intro with lots of pauses in it. It's got two MIDI tracks, the music and the reference. I've stripped out the initial program change, but a piano sound would be a reasonable choice, and the only controller in it is the sustain switch. I'd appreciate it if someone could load this and see if Fit Improv works, or if there's some obvious reason why it shouldn't. FitImprovTest.zip
  15. I have one MIDI track recorded with lots of tempo changes, but with the meteronome set to 120bpm throughout. I created a second MIDI track and manually inserted a note on every beat in the music. Each track starts at 1:01:000, contains a single clip, and is the same length. I select the second track, and invoke Process->Fit improvisation. Nothing happens, no momentary UI freeze, no change to either track, no popup message. I think I'm following the directions to the letter, except that I didn't "record" the second track from the keyboard, but its event list is just a big long list of Note events and nothing else. What could I be doing wrong?
  16. I just upgraded to the latest Cakewalk. I don't know if this is a regression, or a bug I just never landed on before, but I've got a MIDI track that uses CC4 Foot Pedal to control volume, which is initialized to some high value at the start of the track. If I stop playing and then restart, I hear nothing until eventually it encounters another CC4 event, at which point the sound starts again. So it's behaving as though the chase isn't working, even though I've got it enabled. The screen cap below shows the events at the beginning of the track. It starts with CC121 (All Controllers Off) followed by a few controllers including CC4 that have non-default values. The first note is almost 13 bars into the song. I thought perhaps chase is only supported on a few controls, not including CC4, but if I stop and then restart playing just before the first Note On, I hear the sound, so it is chasing. If I stop and then restart after the first Note On, I don't hear anything until the much later CC4. Is there some stingy limit to how far back it's willing to chase? Is this new in this version? I really need it to chase all the way back to the beginning of the track (or until it finds a CC121).
  17. Windows 7, Cakewalk 2019.12 I've recorded a MIDI sequence which plays on an external synth, and now I want to capture the output from the instrument's 48KHz S/PDIF output. Nothing works. I've tried all driver modes, tried different digital and analog input devices, nothing produces a track. MME and sometimes WASAPI starts to play the MIDI tracks, but hangs after a second or a few, not showing any clip on the recording audio track, and with the Now time line not moving. When I hit space bar, it suddenly moves the Now time up to where it would have been, and shows a clip up to that point, but it has nothing in it but some low-level noise. ASIO, WDM/KS, and sometimes WASAPI plays fine, but doesn't create any clip and therefore records nothing. I've fiddled with the Timing Master settings, trying to use the same device I'm recording from as the master, and also trying to use some other device, and neither worked. For ASIO, I've fiddled with settings in ASIO4ALL to no avail. My S/PDIF input works fine with Windows Sound Recorder. To get my music exported, I installed Audacity, pressed Record, then told Cakewalk to play, and Audacity recorded the music without a hitch. So there's nothing wrong with my hardware or drivers. What could be wrong, or how do I diagnose this further? The device settings are pretty cryptic, and don't seem to provide reasonable defaults, so are there some specific settings somewhere I may have missed?
  18. If you move a Program Change, do you expect any preceding Bank CCs to move? Of course you do, and Cakewalk goes so far as to combine them into a single event. This is really no different. A Note on preceded by High Res Velocity and/or Portamento Controller really is a single event, because those controls only apply to that note, rather than setting some persistent values that apply to all subsequent notes. Cakewalk should treat it that way.
  19. I think ultimately that the explicit events and the automation fight with each other, rather than being added or multiplied in some coherent manner. My workaround is simply to turn off automation and pretend it doesn't exist. This means I have to do everything by drawing actual events, but given the available draw tools, that's not too terrible.
  20. Well sure, but if it moves the Note On without keeping the CC84 right in front of it, it breaks it, and it's hard to fix it manually. It works if you move an entire selected region including controls, but not if you drag the beginning of a note in the PRV. Thanks for the pointer to that support page.
  21. Another bit of MIDI semantics that Cakewalk doesn't seem to support: When setting the Now time in a sequence, and it looks backward to see the value of controls, it doesn't stop if it gets to CC121 (All Controllers Off), so it will set values that it finds earlier than that. Minor point, and only matters if you start individual clips with CC121 to have a clean slate, but it would be nice to get this right. If the backward scan encounters this, it should stop scanning, and ensure that CC121 is sent before all the other control values that it found back to that point.
  22. I'm using forced output channels, since everything is recorded on channel 1, so the Event List is all channel 1. The buffer value changed nothing. As far as I can tell, MIDI Event Chase on Play just doesn't work for me, at least for volume. I've attached a screencap of a short track. It starts with a Program Select on tick 0, an All Controllers Off on tick 1, and a bunch of controllers including volume on tick 2, and then the music starts on the fifth bar. There are no automation events. When I start playing from the beginning it plays correctly. If I start just before the notes, I get a loud volume, probably equal to the default automation volume of 101. If I add an automation value of zero at the very beginning, it shows up in the Event List. When I start playing from the beginning it plays correctly. If I start just before the notes, I get the zero automation volume. I tried an experiment with another control number, and didn't have a problem. It seems like Cakewalk really really really wants to have a volume automation lane, because even if you delete it, when you display the automation lane, it shows a dotted line with a default value of 101 for volume. And if you manually set that to zero, it sets it right back to 101 when you play. That seems to override volume control changes when you manually set the Now time, even though there is no automation event to explain its presence. I'm not sure what to do about this. When working on a sequence, I rarely start playing at the beginning, and the volumes are always wrong. I don't know what I'm doing differently from Promidi.
  23. The MIDI spec doesn't tell you how to write a sequencer, but it does tell you what the semantics of messages are. Those two control changes are documented as prefixes that provide additional data to an immediately following Note On, which would be useless if not tied to that Note On when moved by an editor. CC32 through CC63 are the LSBs of CC0 through CC31. They're not often used, but that's what they are, and have been since 1983.
  24. These are Sysex events recorded from an instrument, which uses a Sysex containing program data followed by an NRPN to load that data into a particular channel for playing. It sends this in lieu of a program change if you start a recording (signaled by MIDI Start) with a program that has been edited but not saved. The idea is that on playback, you get the correct modified version of the program, rather than the stored version. These messages come out of the instrument correctly, and they're recorded correctly, but just not played back correctly. I don't see any reason why storing the Sysex into a "sysex bank", and then putting that into the event list, would behave any differently, since it's still a non-channelized thing that is apparently handled as part of a separate stream from the channelized messages. My solution is simply not to use that feature of the instrument, and always start with an unedited program. So that's not really a problem for me, but it does expose something that is wrong with the program, which should be fixed. Is there an official bug tracker that people can post to, or can we only use the forum, and hope someone from BandLab notices it?
  25. I'm doing MIDI sequencing with the latest Cakewalk. It doesn't appear to understand the semantics of CC84 Portamento Control, or CC88 High Resolution Velocity. Both of these are prefixes to the following Note On, and have been documented in the MIDI 1.0 spec for years. If they are present on a track, and I adjust the start time of the Note On, the prefixes are not moved, even if they were on the same tick as the Note On. They should be. By the way, it also doesn't understand the semantics of control change LSBs, except for CC32 and CC38.
×
×
  • Create New...