SOLARIS EXPANDER / EXPANSION - WISH :)

[Hein Eken]

I do not know about the access Virus TI as I only have the first Virus A model here and I guess it has probably been enhanced compared to this model and not only about polyphony.

All Access Virus models incl. Virus TI Snow use 1 SHARC.
Only Virus TI2 uses 2 SHARCs.
It ideally doubles polyphony, as always and depending on complexity of patches.

Virus TI2 is a quality tool for sure, but it´s not my cup of tea.
Using emulated MOOG filters in Virus reduces polyphony dramatically and the preset´s sounddesign is all about music styles I don´t cover.

The concept and philosophy of Solaris makes it the better synth for ME.
For the money of the Solaris keyboard synth, I could eventually live w/ dual timbrality,- allowing splits and layers of 2x 5 (ideally 6 like Matrix-12) voices local and alternately receiving on 2 MIDI channels or playing 1 part local and the other over MIDI and triggered from a 2nd keyboard,- but 4-part MIDI multimode would be absolutely excellent for me.

For the layer feature, it would be essential, layering the same patch and detune should be possible too,- not only layering 1 VA patch w/ another wavetable/vector synthesis or sample OSC patch.

And yes, I know 2x6 voices is impossible because of the "factor 5", so it keeps 10 or becomes 15.

Hein

[HUROLURA]

Just one point: the Virus TI uses Freescale DSP, no Sharc. This one is probably not as powerful as Sharc.
The Virus TI2 is given for 20 to 90 notes depending on patch complexity (according to access music website). More flexible but less predictable, then. Solaris sound engine running at 96 KHz while the Virus would probably have a 48 KHz sound engine, explaining in itself the polyphony difference between both synths. Currently the Solaris does not spare on DSP with not used modules as the Virus does.
The Virus A, B and C used only one DSP. Virus TI and current TI2 are using 2 DSP.

The Virus is for me the VA synth market leader for quite some time now.
But the Solaris is not meant to compete with the Virus as both synths are much too different.

As already mentioned the Solaris is more in the small Virtual Modular synth league (featuring the now discontinued Nord Modular G1 and G2, and the Arturia Origin). As already stated in another thread, the raw DSP power available in the Origin (with 2 Tigersharc chips) is roughly 60 % of what the 6 Sharc inside the Solaris provide. Max polyphony on the Origin can go up to 32, but depends on patch complexity and we also do not have a 96KHz audio engine here. The choices made for the Solaris are more high end/no compromise on quality.

My mockup of the Solaris expander was just meant to relaunch discussion in case it could give feedback to John. I was thinking at it as if I had to contribute to designing such a project. So I started with the idea of what would be the minimal setup which who lead to the most cost effective result: my answer was blind rack unit embedding the Solaris keyboard mainboard while sparing on manufacturing cost and design cost. This one is not the best that could be achieved (as best would be ... the Solaris keyboard as it already has everything). But I was keeping user handling of such a unit in mind. For Solaris keyboard owner, remote controlling both internal engine and rack shouldn't be that difficult to achieve. My concern was more about thinking about alternate solutions to remote control the rack when not owning the keyboard (which once again would stay the best solution as it is dedicated to such use).

I already encountered several times trouble or limit when trying to setup remote control solution in the past because I missed a few features. I succeed to achieve such thing for Noah Ex plugins in the past, not the ideal solution but 95% working solution by using different Midi controller like BCR 2000, Novation X-Station or CME Bitstream 3x. But I tried more recently to achieve similar results with Zarg ProWave Scope plug-in but I missed the possibility to assign a Midi CC message to oscillator or filter choice. To bad as I almost succeed to use my Pro12 ASB as a remote controller for it and only needed to add a handful of additional controllers from a Midi keyboard for example to get full remote control.

This made me think one should be careful to fully implement remote control from every parameters (including oscillator/filter type selection) from external devices to make the unit fully useable (only exception being patch name as there is no display to show it but maybe it could even be added with patch management control message so that designing sound with such a setup could be fully compatible with using it with the keyboard version afterwards).

The multimode discussion, though not directly link to the rack, is also important as it could have also impact on rack implementation and appeal of a rack version for user. On my side, rather than patiently sparing money to be once able to order the Solaris keyboard, if the rack was available for 2000€ with 4 parts multimode, I would start selling some of the gears I currently have in my setup to buy it... And restart sparing process to buy the keyboard later...

[Hein Eken]

Just one point: the Virus TI uses Freescale DSP, no Sharc. This one is probably not as powerful as Sharc.

Sorry Horulura,- I had better said "all Virus models incl. Virus TI Snow use 1 (one) processor and only Virus TI2 uses 2 (two)" and if your line below is correct, I was also wrong w/ the TI (1 proc vs 2).

In fact I didn´t know exactly which processors are used and only knew there´s more or double polyphony since 2 processors were used.
It seems, we don´t know exactly which processors are in use, there are 2 ranges of processor models (Symphony and Star Core) and subdivisions of single core, dual core and quad core available from Freescale.
There must have been a difference between Virus TI and Virus TI2 too,- maybe the TI2 has faster ones or multicore procs.

It´s also questionable if the processors used in Virus TI2 are less powerfull than the SHARCs,- I don´t know and maybe you know more about that.

According to the Virus TI sample rates, I´ve never read any precise infos,- there´s the SPDIF w/44.1/48k which is standard and there are the 192KHz DA converters.
I wonder why they need 192 KHz DA converters for a 48KHz engine,- if it really is a 48KHz engine.

The Virus is for me the VA synth market leader for quite some time now. But for me the Solaris is not meant to compete with the Virus as both synths are much too different.

I was never a hardware VA fan,- never buyed any Access, Nord or other VAs.
I like analogues and the virtual emulations running in Scope (big synths and Modular) are the only I really like and compared to my analogues.
I also like the ZARGs I have as well as my friends Zarg Solaris, he´s running on a multiple PCI card system.
Because of this/his software Solaris, I became interested in the hardware model.

the raw DSP power available in the Origin (with 2 Tigersharc chips) is roughly 60 % of what the 6 Sharc inside the Solaris provide. Max polyphony on the Origin can go up to 32, but depends on patch complexity.

I don´t know the Origin, just because I lost interest in Arturia products quickly but only knowing their VST stuff.
My assumption was always, their VST stuff runs in the Origin.
Is that wrong and does their stuff sound better on the Origin than in a VST/AU host ?
What´s the lowest voice count you get out of Origin w/ most complex patches ?

Anyway,- according to the/a Solaris rack version, it´s all said I think.
John is quiet and he probably doesn´t want to make a rack version even he mentioned a poll.
Seems, it´s somewhat our thread alone here and there are 1 or 2 guys more wanting a rack eventually,- so it won´t come IMO.
I´ll stop here for the time being and wait until it´s valid a rack version is really planned or in production.

Well, I liked that rack mockup !

Hein

[HUROLURA]

Getting a bit off topic now, but ...

Quickly: Access Virus have always been based on Freescale 56k/symphony DSP (as were Clavia, Novation, Soundarts, Waldorf ...). Only change on Access side has been DSP model and frequency. TI2 is just faster as TI DSP. I only know to 96 KHz synth engine: Nord modular G2 and .... Solaris

And I also always preferred the Scope based sounds (being in the Noah, ASB, Scope PCI or Xite-1: actually I do own some samples of each of them, Ok, just one Xite).

Regarding Arturia Origin, I didn't take a chance to compare the Origin sound to their VSTi (I am not really a VSTi user by the way) so I couln't tell you. All I can say to give an hint is that after a few hours of using it I still prefer the Minimax rather than the Minimoog Origin Template. What interested me in the Origin was more the Modular concept being also a Nord G2 engine owner. The UI approach of the Origin is completely different from the Solaris approach and I had a better feeling while trying the Solaris.

And this is the point where I can come back to the topic: please, in case of releasing a Solaris Engine rack, the sound parameter access should be kept as easy as with the Solaris keyboard, and best option to remote control the rack should be the keyboard, just leaving the user forget that the rack is there ...

[John Bowen]

Well, that was quite a discussion back and forth...and I now know that we could sell at least 2 (maybe 3 or 4) of these rack units.

I want to answer some more of the points, but I first want to say that Hurolura, being involved with Scope for some time, knows pretty well the necessary thinking that goes into a small company and what would be most realistic in terms of taking the Solaris into a rack form. That said - there's no decision at this time, but there were a number of things brought up in this thread that made me realize the simple approach that we would have to take probably wouldn't be good enough to satisfy someone like Hein. And it's really hard to say how much extra work it would require, but there's no question that development on future OS versions would be delayed while we figured out some of the extra things needed to make a rack work as described above.

Now I'd like to clarify the DSP/voice issue, and describe how MultiMode will have to work, when we get to that point:

With the Solaris, as you know, we are currently limited to 10 voice polyphony. Each DSP in the synth is capable of producing 2 voices, and one of the 6 DSPs is reserved for the Master FX section, so polyphony is handled by the remaining 5 DSPs. The DSPs are not in 'slots' of any kind, but each chip must be playing the same preset (running the same code). If we could get the code more optimized, or implement some dynamic allocation, it might be possible to get 3 voices running per DSP, giving us a maximum of 15 voices (or even 20 voices with dynamic allocation, if the patch was using just the Waldorf osc type, which doesn't require as much processing power as the other types).

So, you can see that MultiMode would have to work on a per DSP basis. If the most we can ever get is 2 voices per chip, then MultiMode will have to assign voices in sets of 2. (Also, I have specified a 4 part MultiMode, although it would certain be possible to have a 5 part Multimode.)

So, with 4 parts (which is what the UI is designed for), MultiMode voice assignment would be something like these examples (3 options listed):

P1--P2--P3--P4
2---2---2---4
2---4---2---2
4---4---2---X

So, for the first line - Parts 1-3 have 2 voices assigned, and Part 4 gets 4 voices (for a total of 10 voices). The second line shows 4 voices for Part 2, and the third line shows 4 voices each for Part 1 & 2, and 2 left over for Part 3 (or could be for Part 4). If you were making just a split Multi, you'd have either 2-8, 4-6, 6-4, or 8-2 as possible voice configurations.

The other question is the Output Assignment and FX busses. I'm sure it will be requested that we send the 4 Parts to the 4 stereo Output pairs, and the way to do this would be via the FX Channels. Instead of the Input to each Channel being 'Synth', it could be Parts 1-4.

How we could integrate an 'expander' unit into this situation would require a lot more thought and work (i.e., time & money), which is quite limited at this point. I greatly appreciate all of the ideas presented here - you have given me quite a lot to think about.

Thanks so much!
John B.

[HUROLURA]

Just Two question, John.
Are the IO handled/connected to the "Master FX" DSP or are they connected to the "host" Blackfin MCU ?
Is the Master/FX already fully used or would it be possible to have additionnal global FX for each part (at best) ?

From what I understood insert FX (offering decimation, bitchop and distorsion) are just synth modules like oscillators or filters and probably calculated by each of the 5 synth voices DSP. Regarding the Channel FX, I am wondering if it is possible to have the 4 Channel loaded each with 4 FX (chorus/flanger, phaser, delay and EQ) which would mean you could use one Channel for each synth part.

[John Bowen]

I believe the routing is handled by the blackfin, and the DSP that runs the code for the Master FX does have a bit more 'room' in regards to adding a few effects (such as a reverb), however, I don't know if it can run multiples of the 4 effects that are already in there. The way it works is that the effects are in a 'pool', and once you assign an effect to a channel, it is removed from the available FX pool, so I would think there was a reason for this. I'll have to check with them to find out exactly what the limitations are regarding Master FX in a MultiMode environment.

[HUROLURA]

Thanks for the answers John. This help to see things more clearly.

The way the Solaris is set up, though currently only mono timbral, reminds me more the way the Noah Ex was working. Fixed predictable voice allocation rather than fuzzy "try it and see what happen" dynamic voice allocation found in many other synths (including Origin and Virus). I can understand why using or not some quite DSP intensive element in patches can lead towards difference in term of polyphony available. The disturbing aspect is that the user has no clue about the number of voices he could get. And my experiment with AU/VSTi is even more scary. With hardware dynamic allocation synth, the consequence could be voice stealing. On VSTi, you just get some crackles to inform you you are trying to get too much voices compared to the computation capacity making pushing the system close to its limits quite a dangerous job.

In case 3 notes per DSP would be possible any time, the overall voice setting would stay the same with voice setting by group of 3 notes instead of 2.

Currently, with the 10 notes available, 4 parts multi would allow quite some cool things already in a live use situation. One could think that in case you wish to play a monophonic bass or lead sound, the second note would be just lost, but this may be the situation where Unison mode could be useful to faten slightly more the sound. I already have a few ideas about how to use such constraint to get musically interesting results...

[John Bowen]

Using emulated MOOG filters in Virus reduces polyphony dramatically and the preset´s sounddesign is all about music styles I don´t cover.
Hein

Yes, and this is the point - if you want higher quality results with your algorithms, you have to sacrifice polyphony. I had the option of running the Solaris internal calculations at 48kHz, which would double the polyphony, but I was really intent on producing a very high quality product.
(I asked if it were possible to put in a switch for the user to select the processing clock rate, but was told that each algorithm needed to be optimised for a given clock rate, and that I therefore needed to select just one.)
jb

[Hein Eken]

Well, that was quite a discussion back and forth...and I now know that we could sell at least 2 (maybe 3 or 4) of these rack units.

Well John, that´s what I said in my last post by reason how the thread went, but I also think it´s not representative.

... but there were a number of things brought up in this thread that made me realize the simple approach that we would have to take probably wouldn't be good enough to satisfy someone like Hein.

There must be a misunderstanding existing because that´s not true.
I´m the one who would be satisfied w/ a Solaris rackmount as it is feature wise, but I hope for MIDI multimode,- especially for the keyboard Solaris because it should replace another keyboard then,- that´s all.
For a rack version, it wouldn´t be essential to me.
I also mentioned, the other stuff like MIDI over Lan and AES/EBU are wishes,- not more and not less.

I myself, I´m not a developer of Solaris and YOU have to decide what´s doable, makes sense, is possible or is not by whatever reasons like technical, marketing, investment vs sales to expect etc..
In fact I don´t expect anything and wait what happens ...

OTOH, Horulura and me, we´re really interested how Solaris works tech wise and what the limits are to get a idea.

Now I'd like to clarify the DSP/voice issue, and describe how MultiMode will have to work, when we get to that point:

So, you can see that MultiMode would have to work on a per DSP basis. If the most we can ever get is 2 voices per chip, then MultiMode will have to assign voices in sets of 2. (Also, I have specified a 4 part MultiMode, although it would certain be possible to have a 5 part Multimode.)

I think, it´s not a matter of the count of multimode parts.
As I said in former post, I´d probably fine with some kind of split/layer functionality offering a dual-layer mode (6+6 voices, same or different patches, incl. voice detune) and a split mode,- both local or over MIDI,- or 1 part playable across local keyboard and the other over MIDI.

I know, this would be possible to realize only w/ some optimization allowing 3 voices per chip,- and if not we´re stuck w/ the 2-voice per chip specs which makes a split/layer configuration of equal voice count for each part of split/layer impossible.

So, with 4 parts (which is what the UI is designed for), MultiMode voice assignment would be something like these examples (3 options listed):

P1--P2--P3--P4
2---2---2---4
2---4---2---2
4---4---2---X

So, for the first line - Parts 1-3 have 2 voices assigned, and Part 4 gets 4 voices (for a total of 10 voices). The second line shows 4 voices for Part 2, and the third line shows 4 voices each for Part 1 & 2, and 2 left over for Part 3 (or could be for Part 4).

Well, I´d prefer a configuration like 4-4-2-X because it offers at least 2 polyphonic parts and 1 duophonic.
The others are fine too, but the 4th option would be my prefered one.

If you were making just a split Multi, you'd have either 2-8, 4-6, 6-4, or 8-2 as possible voice configurations.

That´s pretty o.k. for splits I think.
Because in theory, it would be possible to create combined split/layers in MIDI multi mode and eventually also local and depending on voice assignment routines,- what about 4 | 4 layered (same MIDI channel) and 2 voices in a separate single split zone ?

The other question is the Output Assignment and FX busses. I'm sure it will be requested that we send the 4 Parts to the 4 stereo Output pairs, and the way to do this would be via the FX Channels. Instead of the Input to each Channel being 'Synth', it could be Parts 1-4.

Yep !
It could also be thinkable to route 1 part to the main outs using the full arsenal of FX and routing the other 3 parts to the single outputs/ add. output-pairs,- in mono or in stereo perhaps and as a user definable routing option.
Me personally, I have no probs using a outboard multi FX box in addition and if it comes to a bass synth part, I´d probably want to have it "dry" anyway.

How we could integrate an 'expander' unit into this situation would require a lot more thought and work (i.e., time & money), which is quite limited at this point.

I don´t even think about the rack unit being an "expander" (see former post), I see it being a MIDI module w/ same features a Solaris keyboard offers, means: If Solaris gets MIDI multi mode ever, the rack gets it too.
If MIDI over LAN and AES/EBU is a no go for you, just only forget it.
It would be ice on the cake for me, but doesn´t make Solaris a bad synth just only because it won´t come.

I greatly appreciate all of the ideas presented here - you have given me quite a lot to think about.

Thanks so much!
John B.

I appreaciate your explanations here too, it helped understanding Solaris architcture and it´s limits.
Thank you very much too !

Hein

[Hein Eken]

- if you want higher quality results with your algorithms, you have to sacrifice polyphony.
jb

I know that from SCOPE and it´s devices as also your Zarg devices,- and I don´t have a problem w/ that.

Any not perfect note stealing/ dynamic voice allocation algo is more problematic than having a 4-voice poly only, since you can express any chord in the diatonic system w/ 4 voices only.
That´s why the Oberheim 4-voice worked pretty well musically.

But some synths need 5 or 6 voices to play a 4-voice chord when using the sustain pedal and cut voices audibly.
There are VSTis needing "hidden voices" to mask note stealing.
That as a general statement.

I don´t say Solaris does,- I can´t because I don´t own it up to now.

Hein

[HUROLURA]

Regarding what John described as the options to share polyphony among the 4 multi parts, I don't think only one of these options would be available but rather all of them to let you set your multipatch polyphony mapping as you will (with same patch on all notes of one DSP rule: currently 2 notes, maybe more later).

And that's where the non compromise design shows its power: everything has been design to be sure to get the 2 notes per DSP in any case. So to push forward towards multimode "only" require to be able to load the 5 DSP with their own patch settings and modify the way MIDI data flow are translated to control the DSP sound engines. While trying the SOLARIS during last Musikmesse, I noticed the care taken to smooth transition from patch to patch to prevent any audible artifact to occurs when changing patch.

I was wondering if different settings could be loaded to each note processed by one DSP. John clearly answered "no". This would have made this as flexible as what is possible on the Xite, but as already said, I am used to such limits with the Noah Ex.

From what I understand, the Blackfin is receiving the note and control to be played either directly from the Solaris numerous built-in control elements (keyboard, ribbon, joystick, sequencer, arpeggiator, wheel, pedal inputs, ...) or from MIDI data coming from MIDI in or USB. Then the Blackfin has direct access to any of the 5 DSP (different to the Slot architecture found in the Xite where DSP available in the same slot are chained and only one of them is directly controlled by the Host).

My conclusion then is as follow:
- to get multimode, most if not all the work has to be done on the Blackfin side
- to get more voices out of one DSP, most of the work would be on the DSP code optimization side

First job would probably require less resource than the second one, and therefore should be the wise path for next update.

Regarding the 3 or 4 units already sold to us, I agree this would probably not be enough to decide to start rack version design. Any poll made here would give more than some hints as we are currently less than 300 members.

There a few other forums with more members where such a poll about a 1U blind rack unit would bring some more interesting figures to help making a wise decision.

I don't think the Creamware Klangboxes were anywhere as successful as the ASB boxes. But the context may have been different as the solution was available as several products: ASB, Klangboxes, but also Scope PCI plug-ins and used Noah units.

But the Solaris is currently available only as the keyboard version (the Scope plug-in either on Scope PCI or Xite is much too different from the hardware keyboard: only the name and principle is common, and limited to just a few notes anyway). So for someone convinced by the Solaris sound, having a cheaper alternative would be much more attractive. And such a unit would also be easier to host for a retailer...

[Hein Eken]

Regarding what John described as the options to share polyphony among the 4 multi parts, I don't think only one of these options would be available but rather all of them to let you set your multipatch polyphony mapping as you will (with same patch on all notes of one DSP rule: currently 2 notes, maybe more later).

I hope so.

My conclusion then is as follow:
- to get multimode, most if not all the work has to be done on the Blackfin side
- to get more voices out of one DSP, most of the work would be on the DSP code optimization side

First job would probably require less resource than the second one, and therefore should be the wise path for next update.

If it works like described,- yes.

So for someone convinced by the Solaris sound, having a cheaper alternative would be much more attractive. And such a unit would also be easier to host for a retailer...

I agree,- and it would be more mobile and easier to service too,- this incl. the shipping to a service center.
As much as I love haptics and displays on new units, I hate these on aged ones.
I´m experiencing a nitemare of work incl. looking for parts since we started replacing all tact switches, knobs, rotarys and displays/backlights on my old gear, just only to get some of these sold next future.
I´m happy I don´t have to replace many caps, resistors and transistors or rare chips in addition.

Hein

[John Bowen]

Regarding what John described as the options to share polyphony among the 4 multi parts, I don't think only one of these options would be available but rather all of them to let you set your multipatch polyphony mapping as you will (with same patch on all notes of one DSP rule: currently 2 notes, maybe more later).

I hope so.
Hein

Yes, of course, the polyphony assignment is programmable per each MultiSet! We have to add a new object to the data structure (MultiSet or Multi or Combi or?) that holds a number of parameters for each Part - Tuning, Octave, MIDI Channel, Program Number, Voice Allocation, Level, Pan, High Key/Low Key, Arpeg On/Off, etc., etc.. There's a lot of work to do, both in defining the UI and coding the system, as all of this is still only on paper. I cannot say when it will happen, but I fully intend that it will happen!

[Hein Eken]

Yes, of course, the polyphony assignment is programmable per each MultiSet! We have to add a new object to the data structure (MultiSet or Multi or Combi or?) that holds a number of parameters for each Part - Tuning, Octave, MIDI Channel, Program Number, Voice Allocation, Level, Pan, High Key/Low Key, Arpeg On/Off, etc., etc.. There's a lot of work to do, both in defining the UI and coding the system, as all of this is still only on paper.

Even being on paper only, that looks pretty perfect as the idea !

I cannot say when it will happen, but I fully intend that it will happen!

Cool !

I understand this will happen (if it happens) for then existing Solaris keyboard instrument 1st and I appreciate that.
IF it will be available for the Solaris keyboard, it would replace an already existing keyboard in my rig,- and in that case, I´d buy a Solaris keyboard.

But IF there would come up a rack module 1st and the features mentioned above would be implemented later and in both the units (keyboard and rack),- I´d buy the rack 1st.

Now, is up to you.

To be true, I planned buying a Solaris keyboard w/ these features mentioned above being implemented after Musikmesse 2013 because I supposed ´em being introduced @Winter Namm and being perfect after Musikmesse.
I hope the same for SCOPE 6 b.t.w. and maybe also ParseQ.
But I also don´t expect reading any release dates here before it´s really done.

I´m sure you´ll annouce all here when it´s being worth to announce.
That´s why I´m here.

all the best

Hein