Quantize MFX Broken - Cakewalk Please Fix !!!

This post actually has a broader scope than just the Quantize MFX, but my main difficulty is with that plugin and the lack of a 3.1.2 release. See below.

There is clear evidence that the MIDI implementaion in 3.1.1 has been reprogrammed, and that the reprogramming has caused problems. One known problem - which Cakewalk is aware of, because I've spoken to tech support - is that the Quantization MFX plugin no longer works properly. On a MIDI track with the Quantize plugin, notes disappear. The problem seems to only affect DXi synths, not external MIDI devices. The MIDI buffer setting does not eliminate the problem - higher values change the pattern of which notes disappear, but I have gone as high as 12000 milliseconds without solving the issue. Uninstalling and going back to 3.0 does not solve the problem. Reinstalling the MFX plugins does not solve the problem. If I bounce audio to clips or tracks, the notes are still missing. Cakewalk's only successful suggestion was to apply the Quantize plugin destructively.

Now I ackowledge that this workaround does work, but it changes the way I approach my creative process, and it is especially frustrating to have features that USED to work stop working. I have read several other posts corroborating this experience, and I have read others still that detail difficulties with MIDI editing, etc. Cakewalk broke their MIDI implementation on 3.1.1, and I there is no indication that it will be fixed before version 4, and there is also no guarantee that it will be fixed IN version 4, which clearly will be a paying upgrade. I went through a similar experience with Coda's Finale, where the transcription quantization was broken from version 2.7 through version 2000 (That's three or four paying upgrades until it was fixed), even though tech support knew about and was able to reproduce my problems. I have been a Cakewalk user since before there was such a thing as a digital audio sequencer, and I have spent money on a bookshelf full of Cakewalk and SONAR upgrades. I hope that Cakewalk handles this issue in a way that satisfies those of us who paid for an upgrade and lost features.

I'm just replying to my own message to bring it back to the top of this list, because it's still an issue for me and for other users.

Yes, I know this is strictly a user forum with minimal Cakewalk presence. I have already spoken to Cakewalk twice on the phone, and emailed them directly. The quantize plugin remains broken when it used to work (before I paid for an upgrade).

I will continue to pursue this issue on this forum and directly with Cakewalk. If I'm bothering you, go ahead and gripe at me. But hopefully you'll see my point as well - that Cakewalk needs to fix what they break. The plugin used to work. Now it doesn't. I'm not the only one on this forum with this problem.

I've also noticed problems with certain synths and just doing a swing quantize. Notes sometimes move in strange ways, or unexpected ways. I always found workarounds so far. But it can be annoying at times.

My playing isn't bad.. timing has always been important to me. But with latency to deal with, we can't always get the notes in there just right - so quantizing is very important.

Well, I'm sure the bakers are listening. Just let 'em know as you have :)

Thanks for the support, Billy.

Quantizing for me isn't even so much a matter of fixing timing, as it is a creative tool. My timing is fine - very tight, in fact. I play keyboard and guitar with a number of national artists on a regular basis. My drum programmer and creative partner is the drummer for many of those same artists both in the US and internationally. We quantize to create a specific feel. Sometimes it's a hard quantize, sometimes it's a very small percentage. Sometimes it's a particular offset to make a track feel more anxious, or more laid back (think of the drums vs. the bass on D'Angelo or Musiq recordings). But all through SONAR 2.x, the quantize plugin gave us the flexibility to experiment with different feels after the fact, in real time, as the track plays.

Without losing any notes. (Just thought I'd get that in there one more time )

Anybody else have any other insight into the MFX or MIDI issues?

Yes, this is a pretty well known issue with most MFX plug ins and sonar 3. I see it most in the Music Lab stuff. Their RnC doesn't work well and forgets notes, doesn't play chords etc. It works with hardware synths and when you import to midi, but not when just playing it. Quit a pain for a plug in I really like. Anyway, hope Cakewalk does a fix in Sonar 4.

Take Care

RT and rjt,

I just want to point out that sometimes Sonar actually makes "improvements" to their code which then causes problems in other plugins which are not updated. A classic example of this - for me personally - was when 3.1b and 3.1.1 were released. I had nightmares. All the stability I had come to know and love about Sonar was out the window. I went bananas/beserk (as some on this forum will attest, grin). I was so upset and of course thought it was Sonar's fault.

It turns out that the "problem" was in my sound card drivers which hadn't been updated for 2 years! Once Aardvark released their new drivers, things go flowing/stable again. That was a VERY difficult period for me. But I was sure it was Sonar's problem - and in fact, Sonar had IMPROVED their product, which caused other problems to be "exposed" (as was pointed out to me). And it was true.

So, unless Cakewalk owns the source code to a plugin, there's not much they can do to "update it". If you're having trouble with a Cakewalk product, then let them know - **** ifyou like (grin); but if it's not a true CW product, I'd strongly suggest contacting the owners/vendors of it.

The CW people DO listen, and DO attempt to correct problems. Anyone who's been involved with Sonar and other CW products knows the people who work for CW are truly committed, very talented (not just as programmers), and passionate about their products.

And, they are listening to all of us. Just keep those cards and letters going, as they say <g>

Regards.

ORIGINAL: RTGraham

Thanks for the support, Billy.

Quantizing for me isn't even so much a matter of fixing timing, as it is a creative tool. My timing is fine - very tight, in fact. I play keyboard and guitar with a number of national artists on a regular basis. My drum programmer and creative partner is the drummer for many of those same artists both in the US and internationally. We quantize to create a specific feel. Sometimes it's a hard quantize, sometimes it's a very small percentage. Sometimes it's a particular offset to make a track feel more anxious, or more laid back (think of the drums vs. the bass on D'Angelo or Musiq recordings). But all through SONAR 2.x, the quantize plugin gave us the flexibility to experiment with different feels after the fact, in real time, as the track plays.

Without losing any notes. (Just thought I'd get that in there one more time )

Anybody else have any other insight into the MFX or MIDI issues?

Thanks for your answer. I am not saying Cakewalk is a bad company or Sonar a bad product. My understanding is that they did not work very closely with other manufacturers, even those who had coded products specifically for Sonar regarding some of their improvements. So, I am no sure that the fix is for Sonar to rewrite their code, but possibly to share a bit more. Anyway, it is all hearsay to me.... nobody tells me anything!

Take Care

I'll kick in that I own third party MFX plugins that seem irrevocably broken under 3.1. Sometimes if you set the MIDI prepare buffer to its highest setting you can somewhat fix the problem, but that brings other problems (trying to use a step sequencer with a 10 second lag time is a bit riduculous).

This is the one bug that I am suprised they have not committed to fixing. MIDI sequencing was the basis of this product line, and leaving it broken indefinately is pretty weak. Nothing aggravates me more than a computer thats 10,000 times more powerful than my Atari 800, that does not seqence as well.

Eric

Wow...

I gotta admit recently I was wondering what was happening to my tracks when I slapped a quantize plugin on them! I had missing notes! Seems to have something to do with cutoffs... I think I fixed the problem with some hand editing.

Now I know... Bummer! But thatnks. :)

cAPS

Hmm, my experience, knowledge, and understanding is contrary to that. I've found the Cakewalk people to be very integrated with other third party apps. Over time, I've spoken to various manufactures/distributors that state frankly they have been in touch with Cakewalk personnel to resolve problems.

However, I think it's safe to say that in a highly competitive market, which music / digital recording /plugins is - there are numerous "gotchyas" and "be carefuls" that all the parties adhere to. However, they all know it's in _everyone's_ interest to cooperate as best they can.

From my perpsective, that's certainly what I've seen. And the ones which don't cooperate, they tend to fall by the wayside anyway.

ORIGINAL: rjt

Thanks for your answer. I am not saying Cakewalk is a bad company or Sonar a bad product. My understanding is that they did not work very closely with other manufacturers, even those who had coded products specifically for Sonar regarding some of their improvements. So, I am no sure that the fix is for Sonar to rewrite their code, but possibly to share a bit more. Anyway, it is all hearsay to me.... nobody tells me anything!

Take Care

Well I too have found Cakewalk to be a pretty responsive company. However, I know that, given it is such a competitive market, many companies have their plate full just trying to get out their products or to make new ones which generate revenue insteading of making their older products function better. Sonar 3 and 3.1.1 have certainly been upgrades (from 2) and I know they are working away on 4. Also, a lot of the smaller companies are in the same boat. For example FXpansion... a very good company, is coding a number of new products and making BFD work better and a number of people have noted there are no drum sets for DR008 (or rather the old links are broken and the promised new links are unavailable). It does take resources to work with companies to make sure these products integrate and apparently that hasn't been done very well with MFX in this pass. As Sonar's own MFX products don't appear to work very well, I guess I am looking to them to take the lead in fixing this.

I certainly hope this does not cause some of the smaller MFX manufacturers to fall by the wayside, or cause Sonar to abandon their MFX plug ins.

Take Care

I have these problems particulary using Battery. Some one told me to raise my audio/midi latency. I adjusted my midi latency to 500ms, which don't seem to cause problems. But with an audio latency of 5.8ms, I can hear the realtime playing response is slower. This isn't acceptable. I will try turning audio latency back down to 2.9ms. If that works (hope so) I won't really be complaining too much.

Cakewalk needs to serious look into this. These kind of features are important to me when I do dance type music where midi timing must be as tight as possible. This should be one of Sonar 4's first priority (help out the dance music writing process). They also need to implement an auto quantize function. If this feature was implemented this would be a viable workaround than using the midi effect (which is more prone to errors).

Then again I can work on my timing, but I don't know too many people who can play 32nd notes as tight as a drum machine/computer can.

hi,

try this:

1) download latest MfxScript version (1.0.0.8 or later)
2) Add an instance of MfxScript AFTER the quantize mfx plug
3) enter the code below (click edit, copy/paste in the editor)
4) save the file (optional)
5) Click the blue arrow to see if the code runs
6) Close the editor
7) Click the 'Plugs' tab
8) Double-click in the A column (means auto start when loading project)
note: the first time you enable autostart, you will have to enter a password (what ever you want)

9) In the track ‘Time’ field enter –960 (do NOT use the numpad, another S3 bug)

10) Save your project

 ' S3 Timing Bug
 ' In the track Time filed type -960 
 '  and place mfxscript AFTER the quantizing 
 Option Explicit
 Const OFFSET = 960 ' 960 = 1 beat
 
 Sub Mfx_OnTrackEvents(Count, timeFrom, timeThru)
   Dim n, ev(7)
   For n = 0 To Count-1
     Mfx.GetEvent n, ev
     If ev(evPORT) < 127 Then _
     ev(evTIME) = ev(evTIME) + 960
     Mfx.AddEvent ev
   Next 
 End Sub
 

I think the bug appends only when using a dxi or a vsti, it looks ok with midiout

marc - what is this supposed to demonstrate?

Eric

Hi Eric,

This is a fix, not a demonstration

All mfx plugs have two main functions, OnInput and OnEvents, in MfxScript I renamed them a bit more friendly, OnLiveEvents and OnTrackEvents.

In this case, the problem is with track events.

OnTrackEvents(Count, timeFrom, timeThru)

This function is called by the host in advance, with events in the time range of 'timeFrom' to 'timeThru'. Now, in the case of a quantizing plug, it may happen that the new timestamp of the event will be smaller than 'timeFrom' or greater than 'timeThru'.
Current S3 will just put these events in the trash box. (bug)

The fix:

If the event timestamp is greater than timeThru, MfxScrip handles them internally, they are put in an intermediate buffer and will be sent to the host at the correct time.

The problem is with events that have a smaller timestamp than timeFrom, inthis case MfxScript can't do anything.
So, the fix is to make the track play earlier, this is why we enter -960 in the Time field of the track settings.
Then, this script will put back the events at the right time, by adding 960 to each event's timestamp.

In mfx, 960 ticks are ALWAYS 1 beat (independent from the project 'Ticks per quarter-note' setting), but for clarity, you should also set it to 960 in the project settings.

That means also that the first event in your track should start at least after the first beat. I always start my projects on measure 2 or 3.

PS: In MfxScript, if an event is buffered, I increase the port value by 127, so I know that I already 'treated' this event, that's why we have if ev(evPORT) < 127 ... in the script.

Current S3 will just put these events in the trash box. (bug)

Hey Marc,

Nice work. Have you sent your findings to Cakewalk? Sounds like with this degree of detail they could fix the problem natively.

Now, will this work in realtime (if someone is playing live through an MFX plug) or does it require 1 beat of pre-roll to work properly?

Eric

Sounds like with this degree of detail they could fix the problem natively

They are aware of the problem, but we'll have to wait for a fix

Now, will this work in realtime

The quantizing plug will not work in real time. You could 'push' events in the future, but it will require a complicated time travel machine to play these events in the past.

More seriously, changing the timestamp in live events works fine .... except for VSTi plugs. (yet another bug)

If you downloaded MfxScript, just try the following script:

' S3 Live Events bug with VSTi
 ' when we play a note on the keyboard we should
 '  hear another one 1 beat later
 ' With a vsti they will 'ring' at the same time = bug
 ' Works ok with midiout and Dxi synth
 
 Option Explicit
 Dim beat
 Cls
 beat = Mfx.GetTicksPerQuarterNote()
 
 Sub Mfx_OnLiveEvents(Count)
   Dim n, ev(7)
   For n = 0 To Count-1
     If Mfx.GetEvent(n, ev) = eNOTE Then
       Mfx.AddEvent ev
       ev(noteKEY) = ev(noteKEY) + 5
       ev(evTIME) = ev(evTIME) + beat
     End If
     Mfx.AddEvent ev
   Next
 End Sub
 

You'll notice that it works fine with midiout or a dxi, but with a VSTi, the second note will have the same timestamp than the first one = BUG.

Try the arpeggiator or the echo plug, once with a dxi and once with a vsti...

Wow!

I just came back to the forum after gigging all weekend, and I must thank all of you posters for shedding some more light on the issue. Impressive work, Marc. I haven't had a chance to try MfxScript yet, but I suspect that I will find myself indebted to you. This could perhaps keep me quietly content until S4. ;-)

Of course, I think we're beginning to see that all it would take on Cakewalk's part to fix the MFX plugin problems with their own plugins (like Quantize) would be to simply release updated MFX plugins to comply with their own redesigned MIDI implementation. It wouldn't require a complete bug-fix incremental version release. From a customer service standpoint, releasing fixed versions of the MIDI plugins is still something they really should do, without making us wait for version 4. Right now they are forcing us to rely on the programming expertise of end users.

Thanks again, Marc.

Well, I was curious as to what Cake would say about the broken MFX plugs ... so I wrote them and this is what they said ...

"Find the file
TTSSEQ.ini in the Cakewalk folder and double click on it. Next, add
this line under the [Options] Section

IgnoreMidiInTimeStamps=1

Choose File | Save and restart SONAR and see if that helps."

I haven't had a chance to try this, but thought I'd share it. Any thoughts as to what this is chnging and if this might damage other Sonar functions?
Peace

I'm posting this information off the top of my head, without double checking it, so it may not be 100% accurate.
But...
If I remember correctly, the IgnoreMidiInTimeStamps parameter has to do with the way hardware MIDI interfaces, especially USB interfaces, handle MIDI timing. Back before there was such a thing as USB, MIDI interfaces connected to computers primarily through internal cards and through external serial cables. Serial ports (like COM ports) are synchronous devices, and the MIDI protocol, which is itself serial in nature, was happy as a clam.

But along came USB, an asynchronous protocol carrying data in packets where information could potentially get "out of order" (as opposed to the serial COM ports, where only one piece of information can travel at once and it's a nice neat single-file line). To get around this problem, various MIDI interface manufacturers devised systems of time-stamping the MIDI data, to be reinterpreted and re-ordered at the driver end. Some manufacturers have even advertised how accurate their time-stamping is when used with their own proprietary sequencing software (like MOTU interfaces with Digital Performer on a Mac).

That being said, I believe the IgnoreMidiInTimeStamps parameter applies specifically to this kind of USB hardware time-stamping, and as such has nothing to do with software synths. The MFX problems that I have encountered relate only to plugin synths, and I think this is true for many of the people who have posted messages about this problem. So the response you got from tech support sounds somewhat uninformed and generic. I'll certainly give it a try myself when I get a chance, but I don't have much hope of it solving the problem for me.

Hope that was more informative than it was confusing.

While I would love to see Cake fix their own plug ins, there is still the question of other companies who offer MFX plug ins and don't seem to be able to get them to work in Sonar. It would be nice if Cake would help them get up and going again also.

RT, your explanation certainly makes sense. It is unfortunate that there is no true fix for the problm right now. Seems like it could be taken care of so easily. Do you have any desire to switch to another sequencer?

1) RT, you are right about the IgnoreMidiInTimeStamps, this has nothing to do with the quantizing plug(s) bug.

2) The bug isn't currently in the mfx plugs.
The host is calling an mfx plug via OnEvents(timeFrom, timeThru) with buffers of events that have a timestamp between timeFrom and timeThru.
Note that timeThru-timeFrom is equal to the 'prepare using ...' setting.
Now it is logical for a plug that deals with timing to sometimes 'move these events either in the past or in the future. Unfortunately, sonar 3.1.1 will discard/ignore events that are outside this window, when sending events to a dxi/vsti.

As timeFrom is always delayed according to real time, it should be possible to move events back (normally about 1 measure).
For events past timeThru, it would be better for the plug to buffer them internally (this is what mfxscript is doing), but the host should keep these events anyway.

3) The bakers are aware of the 'bug' and we can expect a fix in future version.
For now, the only workaround is to either:

a) Apply midi effect, and even in this case, make sure the clip size is big enough to handle eventual extra timing.

b) As I mentioned earlier, change the track time field to -960 and add the mfxscrip with the correct script after the quantizing plug (see my first post in this thread - mbncp).
Everything should work as expected.

c) I haven’t try this, but another workaround would be to set ouput to a virtual midi device and get the events back on another track. (I try to avoid virtual midi drivers, but well, that’s me..)

ORIGINAL: ba_midi

RT and rjt,

I just want to point out that sometimes Sonar actually makes "improvements" to their code which then causes problems in other plugins which are not updated.

ORIGINAL: RTGraham

This is so funny I work in the software industry and this is a universal problem. Who gets priority? Marketing with the new features or the installed base that needs stability? Note: marketing will always win as the company always has the money from the installed base - sad but true.

To adequately solve this you need to split the product into two lines one with a short life cycle that continues to add in new features and capabilities and you of course get the risk of being Production beta testers :-) The other long lifecycle puts in only bug fixes with the goal of stability.

Bottom line, bug fixes need to continue one release back. So, Sonar 3 gets fixes till Sonar 5 is out. That provides a much more workable solution to those that use this software to make a living. Given the loyalty that I see from Cakewalk users they are going to pony up their money for the next release regardless. This just provides much more peace of mind to a working person.

Good Luck!

AXE

ORIGINAL: axe

Bottom line, bug fixes need to continue one release back. So, Sonar 3 gets fixes till Sonar 5 is out. That provides a much more workable solution to those that use this software to make a living. Given the loyalty that I see from Cakewalk users they are going to pony up their money for the next release regardless. This just provides much more peace of mind to a working person.

Good Luck!

AXE

Your whole post was very well put, axe.

While I have been supportive until now about Cakewalk's decision about no more planned updates for S3, I am now becoming quite worried that they are becoming sucked into the buggy whirlwind of yearly production cycles. (Although this may be viewed as a special case, because surround didn't make it into this version for those who need it--and for that "pro" aura.)

I don't want to stop the parade of progress. But I am going to stick with the DAW I have for least a couple of years. Having been in marketing for most of my life, I understand the bottom line realities. But this sloppy pattern of two steps forward and three steps back that some other companies perpetuate--well I just hope Cakewalk doesn't feel compelled to fall into that endless cycle of never-realized potential.

Before someone asks me the question, I have no big issues with Sonar 3.1.1. It's a fine program. In the spirit of axe's post, I would feel a lot better, though, if Sonar 3 had a couple more maintenance upgrades on the back burner. A few bugs here and there--why not fix them? For many people 3.1.1 is rock solid. For a not insignificant minority, problems have been reported. Maybe Cake should take another look.

I just see a fall season with Cakewalk and Steinberg racing each other down to the wire with their new versions. The design meetings for the new logos, glossy brochures and ads are probably already in full swing.

May the less buggy program win.

ORIGINAL: GC San Diego Seth

RT, your explanation certainly makes sense. It is unfortunate that there is no true fix for the problm right now. Seems like it could be taken care of so easily. Do you have any desire to switch to another sequencer?

It looks like Marc's MfxScript plugin might fix the quantize issue. I haven't had a chance yet to try it, but I've read his explanations a couple of times to make sure I understand the concept, and it makes sense.

Despite the issues with MFX (and if Marc is correct about where the problem lies, with MIDI implementation in general), I have no plans to switch from SONAR to another platform. I'm quite happy with the program in general. I've used Pro Tools quite a lot when I have to transfer my material to other studios, and I've used Cubase and Logic on a limited basis. They all have their strong points, but I've been a Cakewalk user since version 2 or 3, and I'm very accustomed to the workflow.

At the same time, I won't be shelling out money for version 4 until I see stability and support for existing versions improve. This quantize situation reminds me of an ordeal I went through with Finale several years ago (back in version 3.5 or 3.7). The quantize algorithm for their automatic transcription feature went haywire on me, creating all sorts of gibberish notes, dropping notes from the staff, etc. Despite numerous calls to tech support, and despite the fact that they could recreate my problem immediately, and despite numerous assurances that it was being fixed, it took THREE more versions before HyperScribe's quantize algorithm was actually usable. Three versions of the same bug. I think it's part of the reason that I now refuse to purchase every upgrade Finale comes out with - I've been happily using Finale 2002 for professional products even though 2003 and 2004 have been released, and I definitely won't upgrade until 2005 or 2006. Finale has grown into a great, stable program, but for me the limited improvements don't justify the annual expense.

I'm hoping I don't have to fall into the same pattern with SONAR. I think unlimited, name-able groups with a group view where you could manage group attributes for tracks, controls, etc. might be the killer feature for me.

I also will not switch from Sonar in the forseeable future... like probably years. But regarding the short/long term bugginess.... I continue to find it odd that Sonar's "improvements" not only effect other developers, but also cause their own plug ins not to work properly. I'm sorry, but I can't see how that is a thoughtful improvment. Maybe I'm missing something. It certainly isn't the first time I don't get the big picture.

Its good to see diehard Cakewalk users stay loyal, but I for one am on the fence. The reason I use Sonar over Pro Tools, Cubase, etc. is the way it handles MIDI. Its simple, elegent, yet powerful. For me, using MFX is an important pat of every project. I dunno guys, but if it aint fixed in version 4 ... well, I'll have to regretfully go in another direction.
Oh, and have you guys seen that Guitar Tracks Pro 3 has a built in metronome? It makes me wonder why Sonar 3 does not ... S

Alright - time to bring this thread back up.

Marc - if you're still out there watching the forum (and this thread), thank you very much for your posts regarding MfxScript. I did finally get a chance to try the quantize fix, and I no longer have missing notes. Of course, if I have an event right at the very beginning of the track it gets lost, but I almost always have a click-in at the top of a song anyhow. I really appreciate the work that must have gone into MfxScript and also into investigating the cause of the quantization plugin problem.

Again, this raises the issue of why it isn't important enough to Cakewalk to fix a problem like this themselves. I'm still not satisfied with waiting until version 4 to see them fix the MIDI implementation that they broke. I repeat again, the quantize plugin used to work. Other MIDI implementation issues used to work (there have been numerous threads on a handful of issues). They have only been "broken" since the latest updates. And again, I have a real problem shelling out money for the next version when I have already lost confidence in the company's support for their product. I'm going to call customer service and complain again, and I'm going to send another email to technical support later this week.

Again, many thanks to Marc for addressing the issue that Cakewalk should have addressed themselves.

It seems clear to me that Cakewalk has an obligation to provide its Sonar 3.xx customers with a free update to fix this bug and the envelope bug. I just bought Sonar 3 thinking it was solid. This post should stay on top until someone from Cakewalk responds.

I think Cakewalk has a pretty good reputation among its user base. I hope it does not behave in a short sighted fashion here.

JeffN

This post should stay on top until someone from Cakewalk responds.

As others have already noted, this is a known issue in SONAR 3.1.1. Specifically it effects only soft synths, hardware MIDI is immune. The general statement of the problem is if an MFX processor is present which produces MIDI event times that are in the future, then these events will get lost.

If the MFX doesn't move events into the future, or if the MFX is feeding hardware MIDI, then the problem won't manifest itself.

This will be fixed in SONAR 4. In the meantime we suggest we use Marc's MfxScript workaround.

quote:

This post should stay on top until someone from Cakewalk responds.As others have already noted, this is a known issue in SONAR 3.1.1. Specifically it effects only soft synths, hardware MIDI is immune. The general statement of the problem is if an MFX processor is present which produces MIDI event times that are in the future, then these events will get lost.

If the MFX doesn't move events into the future, or if the MFX is feeding hardware MIDI, then the problem won't manifest itself.

This will be fixed in SONAR 4. In the meantime we suggest we use Marc's MfxScript workaround.

Wrong answer.

JeffN

Hi Russell,
Glad it works for you.

If you are doing some simple quantizing you may check this script.
It's very basic quantizing with an option for random offset (after quantizing).
Note that it would be very easy to add some extra parameters, so let me know if you need something special, even something that's not on the default quantize plug.

Currently I should be working on the GUI part of MfxScript, so the plugs would have controls to enter the parameters, but instead of working on this, I'm just playing around with an 'arpeggiator-live midi groove sampler' that I created using mfxscript.
In the meantime, you can just save the script with different settings under different names in a given folder, so they will show in the preset page of mfxscript, and you are then just a double-click away.

Note that a right-click on a 'folder' in the preset tree control will open this folder using window explorer.

Now the link:
http://mypage.bluewin.ch/ncplus/download/Quantizing.txt

PS: Off course, if you use this script don't use the previous one and don't use the default Quantize plug. this is an ALL-IN-ONE

Wrong answer.

Well they are two issues.

1) Mfx plugs that create Live events (real-time input) with future timestamps (arpeggiators, echo plug..).
When used with a VSTi, the events get fired at the same time (like setting the echo delay to 0 msec)
And it's ok with midiout or dxi synth
Only workaround here is to use a virtual midi driver.

2) Mfx plugs that move Track events timestamps in the 'past' or in the 'future' (Quantize plugs).
If these events are outside of the current processing buffers they will be lost.
MfxScript can buffer future events, but not early ones, so the trick is to move the events back (using the time field of the track settings), and push them back at the correct position n the script.

To avoid the the 'Time' trick when using the quantize script we could keep the events within the start of the buffer. That means that some of the events (some of the ones you don't hear) would be less quantized or not at all, but a least you would hear them.
If someone can understand what I try to say and is interested in such a plug(script), just let me know.

And be sure that when S4 is coming out and these two bugs are not fixed, it is not ‘yodel’ that you will hear in the Swiss alps

I would love to see this thread stay on top until we get a satisfactory resolution. Ron Kuper appears to be promising that the problem will be fixed in version 4, but that means I have to spend money to fix something somebody else broke. I cannot begin to emphasize how frustrating that is!. Fortunately Marc's MfxScript fix works for me, but I just discovered how much more time and effort it is to insert an extra plugin onto all the tracks I want to soft-quantize and set their times back by 960 clicks. Don't get me wrong, Marc - I'm very grateful to be able to handle the problem at all. But Cakewalk still isn't handling their business properly in this case. The thread about SONAR's audio engine versus Nuendo's gets 9 pages worth of hits and posts, as well as direct involvement from Cakewalk's vice president of engineering. In the meantime, this thread, which deals with an issue that actually directly affects my productivity, constantly gets knocked down the list, and the only response I ever received to my technical support email was "we have forwarded your message to our customer service department."

So Ron, I'm afraid I'm not satisfied with the suggestion to use MfxScript until version 4 comes out. I'm not someone who has to have the absolute latest version of something everytime an upgrade is available. I spend my money when I see that the purchase price of the upgrade is warranted for my needs, and that the improvement in productivity will justify the expense. In this case, the investment in version 3 REMOVED features that I use, and now you're telling me to wait until I can spend more money to fix it, and in the meantime use a solution that had to come from a third party, and which, although I am grateful for its existence, takes extra time - time that I would not have to spend on the issue if the product worked properly in the first place!

I think it's time for me to call Tech Support again this coming week, and send another direct tech support email. This is getting frustrating in light of the issues that get significant attention.

I'm going to have to agree here and hope Cakewalk changes their decision. I don't think CW should delay Sonar 4 however they should provide a patch for the known issues with Sonar 3.1.1 after the release of Sonar 4.

I would purchase a upgrade because it might offer a new products, conveniences, or services for my trade that I can afford. On the same hand I rather switch software companies if I was forced to purchase a new upgrade just to fix a bug from a previous software version. The only reason not to offer a patch for 3.1.1 after the release of Sonar 4 is because you want want more money from us or you don't care what happens.


I hope enough people become aware of this situation and perhaps maybe CW will comply to offering a update patch for 3.1.1 users after the release of Sonar 4.

As others have already noted, this is a known issue in SONAR 3.1.1. Specifically it effects only soft synths, hardware MIDI is immune.

I did have a problem with my yamaha motif rack never able to start on time with the Quantize mfx. I was using usb instead of midi though.

I agree. Between 2.2 and 3, I had a dozen projects including my primary template that simply didn't play half the notes unless the MIDI prepare buffer was at maximum. It essentially made me give up on a lot of 3rd party tools I had purchased for 2.2, through no fault of those tool makers.

Sequencers have handled MIDI properly for 20 years, and its pretty poor when a top-of-the-line package can't handle quantization properly. C'mon, we're talking quantization for gods sake - its the feature launched 1000 80s synth pop bands. Where would synth music be if HoJo, T. Dolby or Tears For Fears had dropouts at random intervals?

Eric

ORIGINAL: RTGraham

I would love to see this thread stay on top until we get a satisfactory resolution. Ron Kuper appears to be promising that the problem will be fixed in version 4, but that means I have to spend money to fix something somebody else broke. I cannot begin to emphasize how frustrating that is!. Fortunately Marc's MfxScript fix works for me, but I just discovered how much more time and effort it is to insert an extra plugin onto all the tracks I want to soft-quantize and set their times back by 960 clicks. Don't get me wrong, Marc - I'm very grateful to be able to handle the problem at all. But Cakewalk still isn't handling their business properly in this case. The thread about SONAR's audio engine versus Nuendo's gets 9 pages worth of hits and posts, as well as direct involvement from Cakewalk's vice president of engineering. In the meantime, this thread, which deals with an issue that actually directly affects my productivity, constantly gets knocked down the list, and the only response I ever received to my technical support email was "we have forwarded your message to our customer service department."

So Ron, I'm afraid I'm not satisfied with the suggestion to use MfxScript until version 4 comes out. I'm not someone who has to have the absolute latest version of something everytime an upgrade is available. I spend my money when I see that the purchase price of the upgrade is warranted for my needs, and that the improvement in productivity will justify the expense. In this case, the investment in version 3 REMOVED features that I use, and now you're telling me to wait until I can spend more money to fix it, and in the meantime use a solution that had to come from a third party, and which, although I am grateful for its existence, takes extra time - time that I would not have to spend on the issue if the product worked properly in the first place!

I think it's time for me to call Tech Support again this coming week, and send another direct tech support email. This is getting frustrating in light of the issues that get significant attention.

I agree. Serious regressions in the code should be fixed in a maintenance release. NOT PASSED ON TO THE NEXT PAID UPGRADE!

The Envelope Bug, this bug, another bug involving broken multiple control surfaces, etc....there are features broken in the current release which users have built habits around using, and then have to interrupt work flow with work-arounds...

Look, it happens. We all understand that. But it's what happens next that I am concerned with:

Paying for fixes to serious regressions is unacceptable! Such a policy is bad, and regardless of whether the competition is doing business that way, it will only lead to an undermining of the confidence which is at the heart of the relationship with the customer.

Come on, Cakewalk! Some regressions are unavoidable. But others are just egg on the face, and how you handle these define the company.

Please continue a long history of impressing me by revisiting the release schedule.

Bump!

ORIGINAL: JamminFool

I agree. Serious regressions in the code should be fixed in a maintenance release. NOT PASSED ON TO THE NEXT PAID UPGRADE!

... ...

Paying for fixes to serious regressions is unacceptable! Such a policy is bad, and regardless of whether the competition is doing business that way, it will only lead to an undermining of the confidence which is at the heart of the relationship with the customer.

... ...

Please continue a long history of impressing me by revisiting the release schedule.

Well said. As much as I would be disappointed to be forced to pay to fix features that Cakewalk broke, I think I would also be surprised. There are a couple of other MIDI and audio hardware and software companies that I am definitely unimpressed with (no need to name names), and from whom I would just expect, and probably accept, a lack of support. I use some of their products anyhow because I already own them and I've learned to work out the glitches for myself, but my intention of purchasing future products from those companies has dropped to near zero. Until now, my experience with Cakewalk and SONAR has been just the opposite. While I understand that version 4 must be a priority and that there are industry goals and timelines and deadlines, I hope that these pressures won't make Cakewalk lose their character as good supporters of their customers. I'm really waiting for Cakewalk to show us that they are continuing their tradition of quality and support.

The fix for the envelope bug is coming very soon, probably this week. It'll be a patch to the VST Adapter, which is actually at fault for this bug.

Right now all of our resources are focused on SONAR 4. In fact any of the 3.1.1 bugs that are getting fixed internally are being fixed within the SONAR 4 development effort. This means that all the testing of these bug fixes is happening in the scope of SONAR 4, too. (This is true even of the VST Adapter patch, but thankfully the adapter is a separate DLL component so have an opportunity to get an update out now.)

That said, we recognize that some of you won't be interested in whatever features are coming in SONAR 4, and will just want to keep working with 3.1.1 with some bugs fixed. So after SONAR 4 is shipped, and only after these bug fixes have been tested and verified as fixed in SONAR 4, can we consider issuing another patch to 3.x.

Thanks, Ron - the info is greatly appreciated, as is your direct involvement in issues on this forum.

(I feel so special now. )

Seriously, I think I can safely say that it gives many of us peace of mind to know that support will continue at least one version back, and we won't be forced to shell out additional capital for bug fixes. Thanks again.

ORIGINAL: As much as I would be disappointed to be forced to pay to fix features that Cakewalk broke, I think I would also be surprised. There are a couple of other MIDI and audio hardware and software companies that I am definitely unimpressed with (no need to name names), and from whom I would just expect, and probably accept, a lack of support. I use some of their products anyhow because I already own them and I've learned to work out the glitches for myself, but my intention of purchasing future products from those companies has dropped to near zero. Until now, my experience with Cakewalk and SONAR has been just the opposite. While I understand that version 4 must be a priority and that there are industry goals and timelines and deadlines, I hope that these pressures won't make Cakewalk lose their character as good supporters of their customers. I'm really waiting for Cakewalk to show us that they are continuing their tradition of quality and support.

So far such companies have appeared to have gotten away with it. If Cakewalk follows suit and adopts such an "expedient" business model, they will have lost a large part of what made them so unique. That being said, the Cakewalk management has been quite visible and responsive in comparison to most other companies.

Sometimes you have to make at least a partial deal with the devil just to stay in business. I just hope Cakewalk can continue to walk that fine line that separates them from the competition. For example, if they decided to add C/R, a dongle, or some other intrusive type of copy protection, the last Sonar song may well be "Goodnight, Irene."

(This is true even of the VST Adapter patch, but thankfully the adapter is a separate DLL component so have an opportunity to get an update out now.)

yes, please keep the adapter seperate from sonar - i had so mnany problems with the combined things in cubase sx (sometimes the main program wouldnt start because of one plugin!!)

jeff

thank you, ron!

that is perfectly acceptable (and much appreciated).

Hey Ron,

So . . . if we're using Dxi plug-ins, or you are using DirectiXer, there are no envelope automation problems?


Roger Windsor

ORIGINAL: raja

Hey Ron,

So . . . if we're using Dxi plug-ins, or you are using DirectiXer, there are no envelope automation problems?


Roger Windsor

That is an interesting point...Console is another DXi > VST wrapper (an loads more) but I don't think it solves the problem either.

The fix for the envelope bug is coming very soon, probably this week. It'll be a patch to the VST Adapter, which is actually at fault for this bug.

when?