by codevyper; Sat Jan 08, 2011 12:17 am
Keep pushing forward with VST. From what I've seen on the Cantabile site's blog page, Brad has already started down this road so rather than pull back and work on other features, complete this first so that Cantabile can exist within another DAW. Cantabile provides features I have a hard time matching in a DAW like Sonar or Ableton and it would be nice to leverage that inside a DAW.
by TiUser; Sat Jan 08, 2011 1:13 am
A VST version would be great but referring to the current non representative poll here just about 1/4 of votes go for that.
But to be complete I have added that to the list on page 1 of this thread now.
...and keep on jamming...
by amagalma; Sun Apr 10, 2011 10:43 am
I would like Cantabile to report the processing latency of each vst plugin (like Reaper does for example). Since, Cantabile is made for live work, then it would be very useful for one to know the processing latency of different plugins so that he can avoid loading the slow ones.
by amagalma; Thu Apr 14, 2011 3:11 pm
TiUser wrote:Interesting idea. I've added that to the list as
*) Analysis function
- VST audio latency report
Thanks! I think it would be more clear if you wrote it as "VST plugin latency report"
Another request I have is about routing:
- the input and output channel assignments should be made per rack and not per plugin
- every plugin that is loaded in a rack should automatically connect its input to the output of the previous plugin (or to the assigned input of the rack, in case it is the first plugin), and its output should automatically connect to the input of the next plugin in the rack (or to the assigned output of the rack, in case it is the last plugin)
This simplifies and makes a lot faster the creation of any routing in Cantabile, without making it less flexible.
by tombuck; Tue Feb 28, 2012 1:01 pm
1) midi device virtualization (including hot-swap capability of usb controller connections)
2) ability to increase font sizes, particularly for set list panel
3) improved crash debugging - help me narrow down a problematic vst, etc...
4) printing set lists
5) session annotations - notes, lyrics, etc...
6) cantabile "slave" - keeping a hot backup computer on standby in case of failure of primary, keeping sessions sychronized
7) anything to continue improving performance, stability, reliability, recoverability.
search capabilities (sessions, patches)
by glenny_g; Mon Mar 05, 2012 8:25 pm
Plus: Cantabile is more stable and has better vst implementation. And the Set List is good in that you can make up a Set from any of your Sessions and sub-sessions. You can't do that in Forte and their scene import is very unstable.
Minus: it is so darn complicated. Just to map channels and ranges and midi CC assignments to a multi-timbral instrument like Hypersonic is a pain. You end up with dozens of filters. And not having them sub-session dependent makes sub-sessions useless to me. So every "song" gets saved as a Session, which is a shame because Sessions would have been a great way to keep all the "songs" for a particular gig/band in one file.
Really, each Rack needs an integrated channel and range mapper in one easy-to-use panel. And that should be active at sub-session level.
Having midi filters at 3 different levels of the structure seems like overkill to me. And I miss the very clear Scene View in Forte (even lets you have your chord chart for each song come up on screen).
I'm going to persevere but I'm really missing just having a simple rack layout with very good integrated mapping and filtering where it's really needed.
by humphrey; Wed Mar 07, 2012 1:40 pm
in principle I agree to your ideas. I have both: cantabile and forte and use them. It's a real pitty as combination of both would be exactly what I'd prefer. There are many additional issues in cantabile forte can't provide but this more "static" rack structure of forte has 2 main advantages: it is much more simple to handle (even though not as flexible as cantabile) and it gives me the possiblity to include samplers / romplers in a way where they don't load there content on every scene change.
It's funny as cantabile nearly has all these features available (problem: only for sessions)! Sub-Sessions could be used in the same way as forte defines racks, if some items already available for sessions could be made available for sub-sessions too. This strongly concerns the midi channel mapping. Using MIDI-Routings in combination would not be the easiest way to realise more complex scenarios like routing different MIDI-Controllers to a bunch of plugs but would be acceptable for me if they also could be stored to a subsession. Same situation for triggers and media-files from my point of view.
Hi tombuck: really great ideas. Specially 4) and 5) seem to be so easy but would be so helpful on stage. I like each of them and would really wish to see them happen. In addition to 7) this can easily be done today. You can setup 2 identical systems.
First problem: for really beeing independent from each other you have to use MIDI instead of USB for all controllers. In this case you have to duplicate any MIDI-Signal and lead it to both systems. A small additional advantage: problems with the connection in MIDI only lead to lost informations, a problem in usb can lead to a crash.
Second problem: You need 2 soundcards and an audio switchbox. In case of a crash you have to switch to the running system by hand.
Some additional thoughts:
1) a small script running on both machines to synchronise changes made on the mastersystem to the slacve system (but I think this was what you meant when you talked of "...keeping sessions sychronized"?)
2) a small script on both machines running as background process controlling each other. In case of a detected crash of one system the system still running controls the switch on the audio box, restarts the other machine and recreates the status of the whole system afterwards. Both scripts could be transferred via a simple ethernet crosslink-cable.
3) Using different (!) hardware on both systems: it is known from embedded systems that redundant cpu-systems have a lack of reliability due to the fact that both machines are identical. This leads to a good change that a crash in one machine also accours on the second one at the same time. Using different hardware with similar performance decreases the chance of a "synchronised" crash.
4) Maybe this one really sounds strange and I'm not sure if there is a rub in it, but: modern PCs are extremly powerful & it is possible to run 2 instances of cantabile at the same time => What about a master/slave configuration of this kind? To point out what I mean: 2 separate cantabile processes are started automatically (one of them in the background), we'd only need one PC, one soundcard, one version of each plugin (!) and even USB would not be a problem any more if the "pre-routing" would be outsourced to a seperate process. Even the audio-routing could be automated. But as I sayd: only a strange idea...
kind regards, humphrey
by TiUser; Thu Mar 15, 2012 11:40 am
Just to jump on your point 4) humphrey - I think there is some truth and some problem here. I can confirm from my own experiences that windows seems to schedule processing time better between parallel processes (programs, instances) than just multiple threads inside a single application. But when it comes to both using the same sound card I guess this benefit will vanish because the sound cards buffer requests put back a certain timing sync on both processes... However I can imagine that your suggestion could be beneficial when both processes use different sound cards...
To be honest - I personally have given up the hunt to use 100% of my cpu for audio. Usual windows scheduling schemas makes this very difficult imho.
In some way things were much simpler with plain midi HW and just linking this via midi, wasn't it?
...and keep on jamming...
by humphrey; Fri Mar 16, 2012 7:36 am
well,.... could it be we have a misunderstanding here? As far as I understood you were watching my idea of using 2 instances of cantabile in parallel form the performance point of view (in simple words: it could be intelligent to split a bunch of plugs into two hosts handling them)? Maybe this is true but to be honest: I dunno.
But: this was not my intention. The idea behind was to have a more stabile system (near to the havarie - scenarios described before) but without the cost overhead for 2 PCs & hardware.
I reflected on the fact that BSODs occoured more or less periodically in former days (Win95 and the like) whereas nowadays they can be observed only sporadical. This means most crashes show up like: one program crashes but the others keep on running as Windows is still active.
So the idea is to start the complete setup twice (and here is the relation to the performance of modern PCs) to have a good chance that one of them is still running when the other crashed.
kind regfards, humphrey
by TiUser; Tue Mar 20, 2012 8:12 am
probably I misunderstood indeed.
However imho BSOD are most likely HW related problems - maybe low level driver stuff too.
I personally use the criticized Win Vista 64 and never ever had a BSOD. I'm not just running applications like Cantabile but also development tools like MSVS 2010 express. But all is damn' stable. However I update my nVidia chipset and graphics card drivers from time to time.
I know that this isn't really a help for others who evaluate trouble - But I think sometimes also good things should be reported, shouldn't they?
...and keep on jamming...