What direction should Kronos take?

[xp50player]

"42 banks mean that the PCG file would be very big and also the time to read this file takes longer (i.e. boot time).
It also would cost about 500 MB? So that would be reduced from the internal memory, which is substantial."

I vote for at least a couple more rows of Program banks. I might buy more content if I had someplace to put it, but I am always struggling for bank space.

[Saxifraga]

"42 banks mean that the PCG file would be very big and also the time to read this file takes longer (i.e. boot time).
It also would cost about 500 MB? So that would be reduced from the internal memory, which is substantial."

I vote for at least a couple more rows of Program banks. I might buy more content if I had someplace to put it, but I am always struggling for bank space.

With modern programming technics you could stream the 'bank data' from SSD. Of course it would not be bank data but data from a sql database, sorted by configurable selects and loaded on demand and not all at boot time.
It would work like spotlight on OS X. Things you needed from the start could be loaded first and would be defined in a set list. You could tag your sounds with any number of dynamicaly allocated tags which you could search for. (You could even search for all sounds who use a specific soundengine and have their filter cutoff modulated by LFO, for example).
Even iOS can do this to some extent with limited RAM and no HD or SSD. With a new OS the Kronos could be even mightier then today and boot faster. If I knew how to pogramm soundengines like Korg AL-1 or GForce minimonsta I would do it myself. But though I know the physics I cannot program that kind of thing sophisticated enough. But I could programm the UI based on Mac frameworks.
I think the main problem is old code and this old MIDI protocol. You don't want software today that uses MIDI to handle the connection between your Application and your Workstation/Computer. A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

[Saxifraga]

...
A modern keyboard has to be functional for a lot of purposes, and there are weighted synth keybeds which I prefer ten times over many real piano actions, when I play a Rhodes part or a synth solo.

I think the main point is piano players are a little bit puristic and don't play Rhodes and no synht. Some I know hate synthesizer.

But if you put a German Grand or Steinway in your workstation the keybed has to live up to that standard. And the Kronos really sounds like one! Best piano sound i heard so far.

[MoonMusic]

I'd also LOVE to see Spectrasonics RMX, Omnisphere and Trilian as Korg Exi banks...Could you imagine Omnisphere in Combi mode? ....moon

[burningbusch]

With modern programming technics you could stream the 'bank data' from SSD. Of course it would not be bank data but data from a sql database, sorted by configurable selects and loaded on demand and not all at boot time.
It would work like spotlight on OS X. Things you needed from the start could be loaded first and would be defined in a set list. You could tag your sounds with any number of dynamicaly allocated tags which you could search for. (You could even search for all sounds who use a specific soundengine and have their filter cutoff modulated by LFO, for example).
Even iOS can do this to some extent with limited RAM and no HD or SSD. With a new OS the Kronos could be even mightier then today and boot faster. If I knew how to pogramm soundengines like Korg AL-1 or GForce minimonsta I would do it myself. But though I know the physics I cannot program that kind of thing sophisticated enough. But I could programm the UI based on Mac frameworks.
I think the main problem is old code and this old MIDI protocol. You don't want software today that uses MIDI to handle the connection between your Application and your Workstation/Computer. A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

You know you go on and on about how great OSX and iOS is relative to the Kronos. Well the iPad 4 has close to the same processing power of the Atom in the Kronos. But it is fantastically less efficient. The sampler in GarageBand provides a max of six notes of polyphony. That's it. Regardless of sample size, six notes. The best sampler in iOS does maybe 16 notes. The soft synths from Apple and others very limited in polyphony as well. Running standlone! It is completely unimaginable that iOS and an iPad 4 could ever allow you to have thousands of sounds instantly available. That you could instantly switch between complex combi setups using multiple engines AND with as close to zero latency as I've ever experienced in a "computer" driven setup like the Kronos. And then add KARMA going on simultaneously, a dozen FXs, and having to process any number of controllers. Disk streaming on the Kronos is glitch free. I have a Mac Pro with 10GB RAM and I still can get glitches when streaming.

The Kronos is a performance machine. I would much, MUCH prefer "old", tight, proven code running a performance machine vs. the loosey goosey, eye candy you find in iOS/OSX land. An app quitting on my iPad is a daily occurrence. I guess just because there's no error reporting, people don't get as upset. Well a crash is a crash and in iOS that stuff happens all the time. Imagine if every time you called up an EP-1 program there was a even a 10% chance it would crash.

I've owned Macs since 1984. I have a Mac Pro 2.8 8-core, a Macbook, many iOS devices (plus a garage filled with discarded Macs & PCs), just about every DAW and hundreds of soft synths and FXs. I use my computer-based stuff heavily but I am keenly aware of its deficiencies. Could the Kronos have a sexier interface? Sure. That would great, but it's hardly critical.

You know over in iOS land, out of all the hundreds of soft synths you'll find there, maybe a dozen of those I would classify as professional. The Korg iOS synths would be on that short list.

Busch.

[1jordyzzz]

With modern programming technics you could stream the 'bank data' from SSD. Of course it would not be bank data but data from a sql database, sorted by configurable selects and loaded on demand and not all at boot time.
It would work like spotlight on OS X. Things you needed from the start could be loaded first and would be defined in a set list. You could tag your sounds with any number of dynamicaly allocated tags which you could search for. (You could even search for all sounds who use a specific soundengine and have their filter cutoff modulated by LFO, for example).
Even iOS can do this to some extent with limited RAM and no HD or SSD. With a new OS the Kronos could be even mightier then today and boot faster. If I knew how to pogramm soundengines like Korg AL-1 or GForce minimonsta I would do it myself. But though I know the physics I cannot program that kind of thing sophisticated enough. But I could programm the UI based on Mac frameworks.
I think the main problem is old code and this old MIDI protocol. You don't want software today that uses MIDI to handle the connection between your Application and your Workstation/Computer. A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

You know you go on and on about how great OSX and iOS is relative to the Kronos. Well the iPad 4 has close to the same processing power of the Atom in the Kronos. But it is fantastically less efficient. The sampler in GarageBand provides a max of six notes of polyphony. That's it. Regardless of sample size, six notes. The best sampler in iOS does maybe 16 notes. The soft synths from Apple and others very limited in polyphony as well. Running standlone! It is completely unimaginable that iOS and an iPad 4 could ever allow you to have thousands of sounds instantly available. That you could instantly switch between complex combi setups using multiple engines AND with as close to zero latency as I've ever experienced in a "computer" driven setup like the Kronos. And then add KARMA going on simultaneously, a dozen FXs, and having to process any number of controllers. Disk streaming on the Kronos is glitch free. I have a Mac Pro with 10GB RAM and I still can get glitches when streaming.

The Kronos is a performance machine. I would much, MUCH prefer "old", tight, proven code running a performance machine vs. the loosey goosey, eye candy you find in iOS/OSX land. An app quitting on my iPad is a daily occurrence. I guess just because there's no error reporting, people don't get as upset. Well a crash is a crash and in iOS that stuff happens all the time. Imagine if every time you called up an EP-1 program there was a even a 10% chance it would crash.

I've owned Macs since 1984. I have a Mac Pro 2.8 8-core, a Macbook, many iOS devices (plus a garage filled with discarded Macs & PCs), just about every DAW and hundreds of soft synths and FXs. I use my computer-based stuff heavily but I am keenly aware of its deficiencies. Could the Kronos have a sexier interface? Sure. That would great, but it's hardly critical.

You know over in iOS land, out of all the hundreds of soft synths you'll find there, maybe a dozen of those I would classify as professional. The Korg iOS synths would be on that short list.

Busch.

Nice, accurate, and sharp opinion.. You are right

[Saxifraga]

You know you go on and on about how great OSX and iOS is relative to the Kronos. Well the iPad 4 has close to the same processing power of the Atom in the Kronos. But it is fantastically less efficient. The sampler in GarageBand provides a max of six notes of polyphony. That's it. Regardless of sample size, six notes. The best sampler in iOS does maybe 16 notes. The soft synths from Apple and others very limited in polyphony as well. Running standlone! It is completely unimaginable that iOS and an iPad 4 could ever allow you to have thousands of sounds instantly available. That you could instantly switch between complex combi setups using multiple engines AND with as close to zero latency as I've ever experienced in a "computer" driven setup like the Kronos. And then add KARMA going on simultaneously, a dozen FXs, and having to process any number of controllers. Disk streaming on the Kronos is glitch free. I have a Mac Pro with 10GB RAM and I still can get glitches when streaming.

The Kronos is a performance machine. I would much, MUCH prefer "old", tight, proven code running a performance machine vs. the loosey goosey, eye candy you find in iOS/OSX land. An app quitting on my iPad is a daily occurrence. I guess just because there's no error reporting, people don't get as upset. Well a crash is a crash and in iOS that stuff happens all the time. Imagine if every time you called up an EP-1 program there was a even a 10% chance it would crash.

I've owned Macs since 1984. I have a Mac Pro 2.8 8-core, a Macbook, many iOS devices (plus a garage filled with discarded Macs & PCs), just about every DAW and hundreds of soft synths and FXs. I use my computer-based stuff heavily but I am keenly aware of its deficiencies. Could the Kronos have a sexier interface? Sure. That would great, but it's hardly critical.

You know over in iOS land, out of all the hundreds of soft synths you'll find there, maybe a dozen of those I would classify as professional. The Korg iOS synths would be on that short list.

Busch.

I think you missed my point. It was not about how perfect iOS and Apple is. I like Apple products and their technology but I am not a simple fan boy.

Of course you need one dedicated board that runs the synth and sampler engines like the Kronos does. The main point of this is to have no interruptions that make normal computers not good at running realtime software and bring us lags and disruptions of the sound. A normal OS X Mac has to much services and other background jobs going on to be as efficient in that regard as the special tailored Linux running on Kronos motherboard surly is. (An Airbus also does not run it´s software on a multiuser environment like Unix, Windows or OS X.)

My point was the, not exactly new concept, of implementing the Client Server model for synth. (I have learned that: Programing Client/Server architectures.)

The .net and Cocoa frameworks implement a model-view-controller approach that isolate the model(synth engine(data+functionality) from the controller (synth API) and the view (UI).
(MIDI does something similar but in a bad disconnected way.)
We need a synth-API that controls the engine so it gets not out of sync but
allows the view to use modern object oriented frameworks.

So basically you have a synth or computer (with realtime environment) that presents an object oriented API that can be compiled into your UI application which runs on iOS or Win or OS X or Linux. (It´s the same thing you have to do if you want to use any functionality that is provided by another software layer.)

You can get rid of lame old MIDI this way and have specifically fast response time and your UI could immediately know the state of the synth which is not possible with MIDI.
MIDI is just sending DATA and hoping for the best. It´s an asynchronous protocol without handshaking mechanism.

So what´s used inside a VST(+ASIO) or AU Unit should also be usable by any touchscreen APP which has to respond as fast as possible and not too construct MIDI messages that will or will not be recognized without the UI knowing.

(That´s why the SoundQuest product seems so slow and outdated btw. Just look how long it takes to load the state of your Kronos the first time they connect. That´s not because of the USB connection and limitations of bandwidth or RAM. "It´s the protocol stupid.")

[Yuma]

Offtopic, yet interesting:

An Airbus also does not run it´s software on a multiuser environment like Unix, Windows or OS X.

According to this website, Airbus runs RTOS, which is a custom build OS designed for real time running.

[BobTheDog]

Your definition of the MVC pattern seems a little wonky there!

It should be :

Model = data and behaviour of data
View = output representation of data
Controller = handles user interaction to control model and view.

The controller is not an API to the data as you have defined but rather is the UI, the Users uses the controller to modify the data.

Also the View is not the UI as you have defined but is just a representation of the data, this may be visual view.


Why you think that a MVC pattern could get rid of Midi is beyond me but maybe all you are after is something like Open Sound Control (OSC) that has been around for years, it would of course be nice if the Kronos supported this but manufacturers have been slow on the uptake.

The use of sysex in the Kronos is not stupid, it is a decision made as it can be used over midi. SO I can connect a Kronos via midi leads to another piece of equipment and they can communicate, I don't need to use a usb lead.

The editor seems slow when you first sync it simply because there is a lot of data being transferred, I don't see the midi protocol making this slow, it will be a simple request data/fetch data thats all.

[Shakil]

"42 banks mean that the PCG file would be very big and also the time to read this file takes longer (i.e. boot time).
It also would cost about 500 MB? So that would be reduced from the internal memory, which is substantial."

I vote for at least a couple more rows of Program banks. I might buy more content if I had someplace to put it, but I am always struggling for bank space.

With modern programming technics you could stream the 'bank data' from SSD. Of course it would not be bank data but data from a sql database, sorted by configurable selects and loaded on demand and not all at boot time.
It would work like spotlight on OS X. Things you needed from the start could be loaded first and would be defined in a set list. You could tag your sounds with any number of dynamicaly allocated tags which you could search for. (You could even search for all sounds who use a specific soundengine and have their filter cutoff modulated by LFO, for example).
Even iOS can do this to some extent with limited RAM and no HD or SSD. With a new OS the Kronos could be even mightier then today and boot faster. If I knew how to pogramm soundengines like Korg AL-1 or GForce minimonsta I would do it myself. But though I know the physics I cannot program that kind of thing sophisticated enough. But I could programm the UI based on Mac frameworks.
I think the main problem is old code and this old MIDI protocol. You don't want software today that uses MIDI to handle the connection between your Application and your Workstation/Computer. A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

sysex is pure binary format, and it is the most efficient format for transfering parameter values. It's like assembly code, pure instructions. No high level libraries to call into for conversion.. etc. SQL database can not match speed of in-memory data transfers. And the iOS doesn't even come close to what KRONOS is doing for you in real time.

Try to load 2000 sounds into your favorite VSTi for instant play back. Even the fastest computer will need some time to load them into RAM. And that may not be much less than what KRONOS is taking.

[Shakil]

A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

Client/Server architecture is not a communication protocol. You still need some kind of protocol to exachange data. TCP/IP is heavy! MIDI Sysex is light! the beauty of sysex is that it can do anything for any synth by any manufacturer. You can dump all settings for the whole studio instruments into one sysex file. The DAW can send back all of the sysex back to instruments, which is the basics of total recall.

[Kevin Nolan]

I realise this thread is quite long and with several threads through it, but feel I need to refer back to Dan's and my posts; which I reread today and feel I've been inconsistent in my reply and, read on its own, looks like it could misrepresent Dan's previous response.

Now understanding Dan's posts more clearly, I feel I may have responded to one of Dan's posts and misrepresented his stand point. My apologies Dan for having done that. I accept that OASYS and Kronos are different instruments at different price points; and I can see that not all Tritons preserved every attribute from the previous one. So I've probably been a little harsh it comparing all the physical features of the Kronso and OASYS and reviewing the Kronos unfavorably in that regard.

In general I'm trying to make a simple point - that the physical and ergonomic package is important in all synths and workstations. Lets leave it at that !!


But the key thing is that I not misrepresent Dan's post which my subsequent reply, read on its own, could read as having done - so apologies for that Dan if I have misrepresented your point - I see your argument better on a second read and just feel I need to stress that one more time.

I'll finish my points associated with this thread on a more positive note - looking at the broad workstation market, both OASYS and Kronos users are still hugely lucky to own instruments with feature sets that are multiples of the competition. given OASYS came out about 7-8 years ago and Kronos 2 years ago, that's saying something. the only problem for Korg is - they have set the bar so high that it'll be tough to beat in whatever comes next!

Kevin.

[Saxifraga]

Your definition of the MVC pattern seems a little wonky there!
If you think so.

It should be :

Model = data and behaviour of data
View = output representation of data
Controller = handles user interaction to control model and view.
I do agree!
The controller is not an API to the data as you have defined but rather is the UI, the Users uses the controller to modify the data.
The user only sees the View on the data the Controller presents to him. It was used by me as an analogy. You are right it´s not the same. Maybe it´s not good to mix procedural terminology with object oriented patterns.
Also the View is not the UI as you have defined but is just a representation of the data, this may be visual view.

Why you think that a MVC pattern could get rid of Midi is beyond me but maybe all you are after is something like Open Sound Control (OSC) that has been around for years, it would of course be nice if the Kronos supported this but manufacturers have been slow on the uptake.
That´s the point where you lose me. Did I say MVC will get rid of MIDI? I ment we need a piece of software 'like a Controller+View' in the MVC pattern' that has direct access to all the functions in the model(synth). So that we can have direct control via WLAN/USB/TCPIP etc. of all it´s functions. That´s in essence my point. So that we can have full controll of the hardware from different machines.

The use of sysex in the Kronos is not stupid, it is a decision made as it can be used over midi. SO I can connect a Kronos via midi leads to another piece of equipment and they can communicate, I don't need to use a usb lead.
Did I say that sysex is stupid?(Ah. I shouldn´t have used that old 'It´s the <insert> stupid.' phrase.) I think old and outdated is my standpoint. And that from the UI perspective. We can still have both.

The editor seems slow when you first sync it simply because there is a lot of data being transferred, I don't see the midi protocol making this slow, it will be a simple request data/fetch data thats all.
You see that´s the problem i think: You cannot control directly the synth with sysex. Let´s say you have wavetables inside the synths RAM. If you want to manipulate them you have to call them from the machine into your computer, have them changed by the user and retransmit them to the synth. You don´t have direct control over the synths RAM. You have to requery the wavetables if you want to know if it worked. You have always to push and pull data without direct response. Normally synth don´t send you error messages you can catch and react to. But maybe I am reinventing the wheel and this OSC thing is what I want. Will have to look it up.

Thanks for the response. It will help me to get to the point where I know what is worth implementing and what I may have misunderstood and is unnecessary.

[Saxifraga]

A true client/server architecture would lead to much better results. Faster and more reliable too. MIDI SysEx is an anachronism now. It should only be used as a fallback method. Just thinking loud.

Maybe I was a bit bold here.

Client/Server architecture is not a communication protocol. You still need some kind of protocol to exachange data. TCP/IP is heavy! MIDI Sysex is light! the beauty of sysex is that it can do anything for any synth by any manufacturer. You can dump all settings for the whole studio instruments into one sysex file. The DAW can send back all of the sysex back to instruments, which is the basics of total recall.

I know that. And you surly now what happens if some of those synth have wrong settings because they were used for a different task or lost their memory and had need of a new battery and all those settings like memory protection make the total recall not happen? Is it not much nicer to save the Kronos mindstate onto the internal SSD then to send it as sysex data over MIDI to your DAW? What if you could do that over WLAN or LAN directly to your computer without clumsy sysex including all the samples?
You still have to hope all sample libraries are where they are needed. You cannot send PCG/KSC etc. from your DAW to the Kronos. Or am I wrong?

Thanks for the discussion! It helps me a lot to get my ideas straight.

[BobTheDog]

You see that´s the problem i think: You cannot control directly the synth with sysex. Let´s say you have wavetables inside the synths RAM. If you want to manipulate them you have to call them from the machine into your computer, have them changed by the user and retransmit them to the synth. You don´t have direct control over the synths RAM. You have to requery the wavetables if you want to know if it worked. You have always to push and pull data without direct response.

This is where you are wrong.

You do not need to pull/modify/push, the sysex on the Kronos gives you functional access to all parameters.

What you do need to do is get any data from the Kronos that you need to display but you would have to do that with any interface.