Granted, Steinberg do has a little way to go in terms of quality assurance (ahem, the VST spec), but I do have a little sympathy for them - I'm sure they didn't think someone would be mad enough to load 10 instances of Halion at once...!

Chris

1. There are 16 channels in MIDI exactly because you can address it in a nibble, and hence do everything on an efficient, low bandwidth 10-bit connection. Steinberg only perpetuate the use of 16 channels because...

2. MIDI is the only universal standard. If you expect a company to attempt to introduce their own standard in an already monopolised market, then wake up and smell the commercial coffee. Give credit to Steinberg for attempting the VST spec, even if there are problems with it (and mostly due to other manufacturers not following the spec properly at that). Incidently, Steinberg do talk about extending it to support >16 channels in the future, but clearly they don't see an immediate demand for it at the moment. If you haven't already, it might be an idea to log on to the Cubase.net forums and let them know you're after it.

3. Computers are not infinitely powerful or infallible. Neither are users and testers. You complain about developers imposing limits on a program so as to avoid overflows and problems (i.e. instrument/sample limits in reViSiT) and yet at the same time complain about a program without limits when it inevitably falls over (i.e. 10+ instances of Halion in Cubase). See the contradiction?

4. Dismissing the entire software sampler market as "crap" isn't what I'd call the height of constructive criticism. You list "Software" in you signature cum resume, why not take a shot at the knighthood yourself? A revolutionary perfect sampler without bugs - how hard can it be?

5. Mind your language.

6. The world is not against you. There is no conspiracy. Do not follow the white rabbit. Buy Coca Cola.

MIDI is a communication standard, I was talking about an internal format. If a softsampler could offer 512 'slots' then this would mean it should listen to 32 x 16 midichannels (via LoopBE for instance). This would mean the communication is still done using MIDI.

The internal format you speak of in this case is the VST spec, but it is also a communication standard (that used by software samplers to communicate) - the fact that it only exists in software (and not hardware) is mere detail. It follows the MIDI limitations so as to be easily integrated with MIDI systems. If it didn't there would be added complexity (and, no doubt, bugs) in its usage.

On Steinberg not seeing demand for 16+ channels atm: then I ask myself: 'Why?' Don't they use huge libraries? Do they only use one Halion instance for the odd drumkit, e.guitar and bass samples? How do some of the Steinberg-creatives create orchestral music then? Do they anyway??

The problem here is that Cubase is used by professional studios, which are usually a little stuck in the past - if they're not using MIDI, they're using VCO! So long as this is the case, 1:1 MIDI / VST equivalence is desirable. It keeps the code simple and means the pro's don't get confused! Hans Zimmer, someone touted as "on the edge of technology", may use Gigasampler, but via numerous dedicated PC's, communicating via MIDI, naturally - three AMT8 MIDI interfaces (24 MIDI interfaces in total = 384 MIDI channels).

However, Halion can still be used quite effectively in a single instance, though I have on occassion had to stretch to two (I also have external MIDI synths supplying some voices at the same time). Granted, the input is limited to 16 channels, but that only has to cover the currently active instruments - one channel can be used for multiple articulations or even instruments that aren't playing simultaneously. Inside Halion, you can set up a large number of programs (100, is it? I forget) in a bank, then use automation to select which one is active at any one time for a particular channel.

IT2 (or any mid-modern tracker) proves that the internal format doesn't need to rely on any external communication standard. In theory (when using all the internal 255 voices (NNA's)) each sound it plays could be a different one. There's no multitimbrality issues there, simply because there's only its internal format, and no-one else around to limit it.

But as an internal-only format, it's fairly restricted in application and unsuitable as a standard for plug-in communication. And don't go thinking it doesn't have it's limitations and nuances either - or that it isn't bound by a de facto tracker specification. Much of the processing is a direct descendent of older trackers - not just Scream Tracker, but Amiga trackers! It inherits all the foibles - for example, a pitch/volume/panning slide is not smooth even if it sounds "smooth enough" - on the first frame of each row the slides don't have any effect, only on the "non-row" frames, even if the slide has been started several rows ago (see the help file in reViSiT on the Dxx effect). So, effectively, the slide is stepped. It has to do this so that people loading old modules have them sound right, but it's far from ideal. And even where IT2 innovates, there were limitations - for example, you couldn't have a volume entry and a panning entry on the same row.

I don't see how my computer would face a limit when 10 Halions and ~50 channels (some of them are layered also) show me 20% CPU usage. The revisit/halion comparion isn't really valid I think as those 'limits' are based on different choices. Tell me, why did you choose '100'? Was it because this number is ST3/IT2 legacy? I'm not quite sure unless you confirm/deny, but I think it is.. :P

Your computer isn't the problem. It's the option of even having multiple instances of a single plug-in - Cubase / VST isn't designed with it in mind. It goes all the way back to how DLL's work in Windows and the architecture of the plug-in, but it turns out that certain variables end up placed in memory that is shared by all instances of the DLL. It's like having an general election and having everybody use the same piece of paper to cast their vote. These problems can be got around, but it takes a lot of work (you're into concurrent programming, something most programmers don't want to think about!), and even more work if you have to go back and rejig an existing plug-in to be compatible.

The "limit" I talk about that would prevent this would be for the host to actively forbid multiple instances of single plug-ins. Steinberg chose not to implement the limit on the possibility that the plug-in designer has accounted for the problem, but most haven't - and hence you have the possibility of it working, not working, or crashing. You have to way up whether you want flexibility-and-risk or rigidity-and-safety - the choice is the same in both the scenarios I mentioned (reViSiT instruments and Cubase plug-in instances).

You're right, the 100 sample/instrument limit was taken because that was how it was in IT2 (ST3 had no "instruments"). However, I did consider the limit at the time. In my experience I have rarely come across an IT file that used more than 30 or so instruments. My own IT endeavours sometimes had instruments in all 100 slots, but most of them would be unused - for finalising files, I would have to go through and weed these out to optimise file size. And, yes, I wrote for orchestra even then - and I also invariably used several MIDI instruments. In fact, the limitation I found most castrating was not any limit on instruments, but the fact that you only had one MIDI device to play with, and although I rarely had 16 channels in use, I did want to send 4 channels to one device, 4 to another, 5 somewhere else, etc. And a MIDI chain is not a pretty thing...

I call it crap because all the attention seems to go to shiny flashy knobs, buttons, small interfaces (I don't dare go 1600x1200!), mouse^2 interfaces, clicks-heaven, RSI-divinity etc. etc. I don't make this up, I read it everywhere on fora. People complaining about aweful interfaces, people complaing about 2-pixel movements with the mouse to add/sub 6db (while running 1600x1200 ofcourse, so you can imagine what 2 pixels look like) etc. etc. Most attention goes to what things look like rather than bugs everyone complains about and interfaces that everyone complains about.

I agree - I think far too much time is spent on skin options and flashy interfaces rather than ergonomic ones. And it is usually the case that the computer is slowed down by these affectations. However, it's not the companies' fault; it's the users'. Truth is: a plain, yet ergonomic interface will not sell a product, but an aesthetic one will. The first byte is with the eye.

Meanwhile I found this link, it might change the whole story about the Halions, if SX3 has this 1.5Gb limit ppl talk about. When using all these 10 Halions, my taskmanager *does* report about 1.5Gb here as well! (doesn't explain why Kontakt would crash, but alas..) .... So, perhaps it's a Cubase issue? I re-designed my Halion banks so that all strings/wood/brass/percussion fits in 5 Halions. Lotsa keyswitching) But only 3 Halions are properly loaded then, the 4th one is only half-loaded.. if I'm lucky. If I'm less lucky, cubase would just crash. This could mean that the amount of instances wouldn't matter at all..

My guess is more than one instance and you're in "undefined" territory. Try a different host - there might be ones with better memory handling policies. I recommend taking a look at Tracktion - though it itself is not free of bugs and I haven't tried it with multiple instances. Also, for easy instrument routing, energyXT is the bees-knees - and you can use it within Cubase or Tracktion. It might be interesting to see if a Halion / reViSiT patch inside an energyXT plug-in itself inside Cubase still suffers from your problem. (?)

Also, it certainly looks like the professional choice for software sampling is GigaStudio. It operates on an entirely different principal to most other software samplers - as a completely seperate application that uses its own MIDI loopback device - not a plug-in, not VST. The "Orchestra" version supports 8 MIDI devices - so it will appear as though you had 8 samplers loaded, yet only address the single GigaStudio instance. For serious sampling, this is definitely the most logical architecture choice. And guess what - you can use reViSiT to send MIDI to it directly, and still process the sampler's output in your VST host, using Rewire. If the interface has been given anywhere near this amount of thought, perhaps it's not so bad... And GigaStudio (then GigaSampler) started as an independent small-label product (as did Tracktion) - always a good sign .

Good luck,
Chris