Does Catanya arpeggiator work in 64 bit Sonar??

Well I can answer half your question.  I'm working in Sonar 32-bit and Catanya does work -- exactly once.

Sonar has a long and well-documented problem with handling multiple MIDI-Enabled VSTi plugins.  It you want just one instance of one MIDI VSTi then it works just great.  But two or more MIDI VSTi's will often lead to heartbreak, frustration and lots and lots of crashing, as well as long exchanges with the overworked Support folks.

If you're committed to using Sonar as a DAW then I strongly recommend that you subhost your MIDI VSTi plugins through something like Energy XT.  This provides a much more flexible and stable working environment for MIDI VSTi's like Catanya.  Obviously if MIDI VST instruments are your primary reason for having a DAW then this is particularly unwelcome news.  Fortunately Energy XT is cheap and pretty intuitive to get up and running as a subhost without needing to learn the program from end to end.  It's a stopgap solution while we [continue to] wait for this bug to be addressed.

Hopefully someone else can comment on the 64-bit aspects...

I'm not suggesting you stay away from Catanya.  I quite like it!  And Thesys makes a great companion to it.  But if you're a MIDI based musician then sooner or later you're going to run up against the problem and energyXT makes a pretty tidy solution for the time being.  It's a nodal program so the routing of MIDI is easy and intuitive.

It's unfortunate that you need to add yet another DAW type package, but that's not really 7 Aliens fault.  It's a Sonar issue, not a Catanya issue.  Get ahold of some demos and give it a whirl.

Have you tried the demo?  Using 32 bit, the demo didn't work for me on DXi synths (tts-1) but I took a chance and the full version work well.  Just don't expect more than 1 instance. To me, if it works with bitbridge in the demo, you should be fine.  Try multiple instances too, to see if it work for you, and post your findings. 


I agree 7Aliens haven't been too responsive thus far, however I've found them posting to other forums:
http://www.kvraudio.com/forum/viewtopic.php?p=3709025

In relation, he claims to 'use at your own risk' on Win 64.


To the group, is it worth it for all of us to opening up a trouble ticket to Cakewalk on this issue?  I just have a feeling that there would be fingerpointing back and forth.  Of course Dim Pro, Rapture and others all work with multiple instances because of either partnerships or extensive testing.  Would be cool if we can get them to talk to each other.

It also doesn't make sense to me that Catanya needs an audio track.  I see that there's options in the VSTi to turn it off, but didn't work for me.  Can only get one instance to work thus far. 

Catanya is a very cool plugin, even if only one instance.  The patterns alone are quite amazing, and the interface is quite nice.  After seeing the 'working' Sonar Arp and being stuck with presets, I had to have it.  I felt like I was writing a Billy Joel track with some of the ballad piano presets.  It's a nice tool, and is quite exciting to work with.

At worst, you can bounce to midi clips and move forward with other tracks.  I'd rather have the multiple instances though.  That was a selling point for me.

Just strange that we can run multiple copies of Dim Pro, Rapture, etc. but not of Catanya, which seems to be less intensive, as it generates midi.  I bet it's some audio issue that causes the hang.
 

If any one is interested...I tried a slightly different set up and got essentially the same results.  (a little more stable, but still un-useable)

I used 2 midi and 2 audio tracks for each instance of Cantanya.  And I set up 3 instances of Catanya again (12 tracks in total)  (did not use simple instrument tracks and did not use synth rack.  I inserted all vstis in fx bins)

Now the project seems to be able to play continuously, and with very low CPU usage, but as soon as you touch anything (any Sonar transport function, change arp pattern, open up soft synth, etc. etc. ) Sonar crashes.  (What Sonar does is freeze up and play a continuous low tone until you ctrl-alt-del the program - this is probably my driver - you may get different results ?? )

Brammer -  I am running 32 bit - how will a 64 bit version fix things if there is a basic mdi mapping / buffer issue using midi output enabled vsti's as greysound has indicated ?

Jeff

 
I finally received a note from 7alens, too, saying that they're looking into it.
 
I submitted a ticket to Cakewalk, regarding this: CWBRN-2296  just not sure how it will be handled.
 
Greysound, saw your add to the   "Cakewalk, any new info on THESE bugs"
 
http://forum.cakewalk.com/tm.aspx?m=1643436&high=enable+midi+output+bug
 
I tried to add some additional detail to the ticket, but no dice thus far.  I suggest another Sonar/Catanya user add another ticket, specifying the above thread.

Yendor


 
I finally received a note from 7alens, too, saying that they're looking into it.
 
I submitted a ticket to Cakewalk, regarding this: CWBRN-2296  just not sure how it will be handled.
 
Greysound, saw your add to the   "Cakewalk, any new info on THESE bugs"
 
http://forum.cakewalk.com/tm.aspx?m=1643436&high=enable+midi+output+bug
 
I tried to add some additional detail to the ticket, but no dice thus far.  I suggest another Sonar/Catanya user add another ticket, specifying the above thread.

 
Interesting. I was just reading through this thread and was going to post a comment that I believe this is related to the issue I posted on that website, but you beat me to it!
 
So this is the first time I have read about confirmed crashes related to this issue. On the website I speculated that I believe it could cause crashes, but it was only a theory at that time.  This is a serious bug, but unfortunately Cakewalk seems to completely ignore it, even after it has been brought to their attention a long time ago. I think the reason is because you cannot reproduce this problem without using a 3rd-party VSTi because there is no VSTi that ships in Sonar that sends MIDI out (where you need to check "Enable MIDI Output" on it). And because you always need a 3rd party VSTi, Cakewalk can conveniently say it is not their problem.
 
Personally I run into this problem every day. You need just one plugin sending MIDI output to experience the problem. When I have a VSTi sending MIDI out, and I record MIDI on a completely unrelated MIDI track using my MIDI controller, I constantly get notes that are cut short, missing notes, etc in the recorded clip. I have to go to the VSTi sending MIDI notes out and completely disable it in order to successfully record MIDI on unrelated tracks.
 
And just to describe the problem in more detail, here is a repost of something I wrote in a different thread:
 
From a technical point, this bug is caused by buffers that are not thread safe. This means that if you have different threads doing their own thing (like in Sonar), and those different threads all access the same buffer in memory, one thread can change the contents of the buffer while another thread is trying to use that same buffer. The end result is unpredictable, and can be any type of weird, unexpected behavior including things like corrupted data (stuck notes) and random crashes. 
 
I have carefully looked at the memory that Sonar uses when it sends a MIDI event to a plugin. I noticed that even if there is just one MIDI event, the memory buffer is clearly allocated to be able to contain many events at the same time. This seems to imply that they don't allocate the memory specifically for each event, but re-use the same memory over and over. That makes sense since if you want fast performance, you don't want to re-allocate the memory over and over. But this also seems to imply that the buffer can potentially be used by other threads, when they should have allocated such a buffer for each thread, as opposed to re-using the same buffer between multiple threads. That is a big no-no in a multi-threaded app. You can actually re-use the same buffer in a multi-threaded app if you use a monitor/lock that prevents multiple threads from accessing the same memory at the same time. In such a case, just before a thread wants to use the shared memory, it acquires the lock. If a different thread tries to do the same thing while the first thread still has the lock, the second thread will become blocked until the first thread releases the lock, allowing the second thread to wake up and acquire the lock. These are all standard multi-threaded programming techniques.
 
But in the case of Sonar, I did the following test: In my test plugin, when I receive a MIDI event, I make a local copy of the contents of the buffer that Sonar presents to me. At the end of the same function, I compare the local values to that of the buffer again. Initially, the values would match as you would expect. What I did then was add just a very small amount of delay from the time after I copied the values, to when I check the values again. What I found was that the values no longer matched what was in the buffer. What happened in this case was that my thread was pre-empted, and a different thread than re-used the same buffer, resulting in the contents of the buffer being altered while my VST was still in the middle of processing the events. This is really a serious bug and should not be happening in a mature product like Sonar. I believe this is the cause of all these weird MIDI related bugs, and possibly even some crashes.
 
Now if only we can get Cakewalk to start paying attention to this, but so far all of our efforts have been fruitless...

Yendor


For what it's worth, I got a canned update on the Catanya Issue trouble ticket: CWBRN-2296

"...the status of your report has been changed to 'UNDER INVESTIGATION' with the following notes:
Thank-you for your report, we are still actively looking this issue and hope to address it in a future release"

Silktone - thanks again for all your hard work!  Would love to pick your brain on VSTi development one day!

No problem. I'll answer whatever questions I can. I am not a VST expert and do the VST programming as a hobby. I am a (non-music-related) developer by day though.
 
I wonder if it might be worth my while to try again to get Cakewalk to look into this issue. I gave up logging any more Sonar bugs because I just got jaded by Cakewalk's complete lack of interest in looking into this serious issue (actually, so far none of the bugs I filed with Cakewalk have been fixed, hence me giving up filing any more bug reports). I'll send them an email to see if I can get an update of some sorts on this particular issue as it is pretty serious (crashing and such...).

Unfortunately I have a feeling Cakewalk is going to continue ignoring this issue...

Of Course they are!! Only a hand full of people use catanya, its not in there best interest to fix it as they need to fix more important issuse's , maybe if were lucky it will be addressed in Sonar 9 or 9.5.222, we have a better shot of 7-aliens coming up with a hotfix. and I dont for see that either, 

Some more hope here...

I got another update on the Catanya Issue trouble ticket: CWBRN-2296 
"Thank-you for submitting your problem report, you are receiving this message because the status of your report has been changed to SUBMITTED TO DEVELOPMENT. With the following notes:
Thank you for your report. We have logged this issue with our development team and hope to address it in a future release."

We shall see!   

See this:

http://forum.cakewalk.com/fb.ashx?m=2758584