Real time demos over the 'net?

[sullivang]

Have any library developers considered providing the capability to try the libraries remotely, in (quasi) real time, over the network? I.e, the user sends MIDI over the internet to a server which is executing the library, and the audio data is then transferred back over the net. Sure - there'd be a disconcerting note-on delay, but I have a feeling it would still be somewhat useful.

I know this general concept isn't new - I've heard of net jams, etc etc. But I've not heard of this being done to audition sample libraries - has it been tried yet?

Piracy would be a risk, but perhaps there are ways to greatly reduce that risk.

Greg.

[Michiel Post]

You can always send us a midi file and we will create a rendered piece of it with a piano of your choice so that we can upload it to our website or send on cd if it's large. Most library developers do this when you contact them privatly.
Your idea would consume a lot of data bandwidth and possibly even enable people to create a usable track from an on-line demo. Something that we want to avoid.

[sullivang]

Sorry - did someone say something? I can't hear you - I'm having *oodles* of fun playing the DEMO version of Applied Acoustics Lounge Lizard Electric Piano.
127 velocity layers. Downloaded in no time.

Greg.

[leogardini]

This idea makes no sence and your reply to Michael even less!!!

[sullivang]

This idea makes no sence and your reply to Michael even less!!!The point is this. I am sitting here playing a demo of an instrument in real time.
I have not purchased it. I am able to test it thoroughly, in the comfort of my own home. Yes, if I really wanted to, I could make a complete track with this demo. Why is the risk any greater with a 1GB acoustic piano library played over the internet?

I enquired about auditioning an electric piano library with a local dealer a few days ago. I am still waiting for them to get back to me. Maybe I'll buy this physical modelling electric piano instead - it's damn good, and I have been able to verify it instantly.

I've tried Michiel's 1 octave (+ other sparse single notes) Emperor demo. It was the most frustrating experience not being able to play whatever note I wanted. :) (I got pretty good at improvising in the chords of C and G though ;) ;)

Is this any clearer?

Greg.

[Will Loconto]

Yes, if I really wanted to, I could make a complete track with this demo.

This is why some developers would never consider your idea. For some, it is just an unacceptable risk.

[Frederick]

Michael Post's idea seems the most logical approach. Contact them privately with a midi file.

[sullivang]

This is why some developers would never consider your idea. For some, it is just an unacceptable risk.Yes, fair enough, but I don't think the overall risk is great. It would be a real hassle. This particular demo version fades out to nothing and back again, every 20 seconds, can't save presets, and stops altogether after 20 minutes (or so). I think it's small minded to think that this would reduce sales by any significant amount. Despite these limitations, I'm still able to test it out very thoroughly.

Greg.

[griels]

How about soundware manufacturers 'rent' time streaming the samples, using a lossy sample format, and then when it comes to mixdown, you can use a lossless format?

You could bypass the network latency problems by precaching the start of each sample, Giga style. The technology is pretty much here already to do this (although the security isn't there). You could use a VPN-based Samba share, sfz, DFD and a large precache setting (sfz supports .ogg compression, so shouldn't need too much bandwidth). However, the idea I have wouldn't allow the actual downloading of the entire multisample (that would be madness), just the streaming of it using a special interface (possibly a dedicated player VSTi). Also, the sustain section of the samples could be mixed together at the server end, to reduce bandwidth concerns, and keep the raw sample data at the server end.

Network access would be provided on a $ per MB transferred basis. So it wouldn't be a free demo (although you could offer an introductory scheme, provided you carefully verified the user's identity to prevent freeloaders), but relatively cheap. You could even move to a rental only model, where you didn't even sell physical media... And there would be no concerns about piracy, as noone except the manufacturers would have a complete copy of the sample data.

[FV]

Hi,

Even if the cost to "rent" time streaming samples was fairly low, someone would complain and cause a big ruckus eventually. They would essentially say things such as "they want us to rent in order to demo something? - when I go to Banjo Ctr, I can demo things for free - this is ridiculous". Typically, after the initial period (where people remember how things used to be) has ended, someone who does not remember the history of how it came to this will be the first to complain and there'll be a whole gangload of people doing the same.

Also, while the sfz suggestion isn't necessarily a bad idea, many of these new libs are Kontakt-based or even have their own player (ie DFH Superior). A bunch of reprogramming has to go on. That takes a lot of time and money in order to provide this type of demo. Yes, in terms of technology, we have streaming from a hard drive. We do *not*, however, have technology which streams from a hard drive and streams over the internet. I think that this part of it has many technical issues that would need to be resolved before even thinking about implementing such a solution.

Even though you suggest that it shouldn't need too much bandwidth, I disagree. Even using a compression scheme, when you're streming a bunch of samples over the net, there are still large bandwidth issues. Where would the audio be cached when using a large precache setting? If it is cached at the server, the server would need tons and tons of memory and then all of the audio for each sample would still need to be streamed as notes are played. You could easily use up more bandwidth than streaming a stereo mp3 (think of each note as a stream). If the audio is cached on the downloader's computer, well that is even worse because you must download a "precache" of every sample to your computer. Just starting it up would require huge bandwidth. This is just from a single user. Multiply this by multiple users.

In regards to the rent-only model that you perhaps suggested, That opens up a whole new can of worms. How is there any way to control that the samples will not be resampled?

Anyway, it's nice to see some people thinking about this issue. Even though there may be unworkable ideas, people suggesting and coming up with different and inventive ideas will one day yield a good solution to this. I don't think that we're quite there yet. Solutions like this require creativity but perhaps also lots technical ingenuity too.

Just my .02
FV

[Jordo]

You can not play in real-time over the net. IT is not possible, which is why you have to download it so you can 'demo' it locally on your computer. To page something in your computer's cache is the best, memory is about 100x slower than cache, and paging your harddrive is let's say about 100x slower then memory. avg time to seek a hard drive would be about 4 milliseconds so at BEST you might be able to ping a web server at 0.15 seconds. Playing in real-time over the net with these librairies is just not possible. You just don't have the speed nor the throughput.

Best idea I've heard in a while is the idea of privately sending them a midi file, and beging able to hear the rendered version. What more could you ask for? You could get to hear your whole song to demo the overall 'sound quality' and you also have an octive to play with to demo the 'playability'. :) Two thumbs up to PMI.

[sullivang]

I think the idea I initially proposed would work. The synth runs on the *server*, and streams MP3 (or whatever format is most appropriate) back to the user. There will be a note-on delay, yes.

Totally agree about the *non* feasibility of streaming the samples to a client-side synth, caching or no caching.

Greg.


You can not play in real-time over the net. IT is not possible, which is why you have to download it so you can 'demo' it locally on your computer. To page something in your computer's cache is the best, memory is about 100x slower than cache, and paging your harddrive is let's say about 100x slower then memory. avg time to seek a hard drive would be about 4 milliseconds so at BEST you might be able to ping a web server at 0.15 seconds. Playing in real-time over the net with these librairies is just not possible. You just don't have the speed nor the throughput.

Best idea I've heard in a while is the idea of privately sending them a midi file, and beging able to hear the rendered version. What more could you ask for? You could get to hear your whole song to demo the overall 'sound quality' and you also have an octive to play with to demo the 'playability'. :) Two thumbs up to PMI.

[griels]

Hi,

Even if the cost to "rent" time streaming samples was fairly low, someone would complain and cause a big ruckus eventually. They would essentially say things such as "they want us to rent in order to demo something? - when I go to Banjo Ctr, I can demo things for free - this is ridiculous".

Well, seeing as you can get a 100% quality rendering with my proposition, I see little to complain about.

Typically, after the initial period (where people remember how things used to be) has ended, someone who does not remember the history of how it came to this will be the first to complain and there'll be a whole gangload of people doing the same.

Also, while the sfz suggestion isn't necessarily a bad idea, many of these new libs are Kontakt-based or even have their own player (ie DFH Superior). A bunch of reprogramming has to go on. That takes a lot of time and money in order to provide this type of demo. Yes, in terms of technology, we have streaming from a hard drive. We do *not*, however, have technology which streams from a hard drive and streams over the internet. I think that this part of it has many technical issues that would need to be resolved before even thinking about implementing such a solution.

Well, admittedly the horse has bolted from the stable door to some extent with the existing libraries. Although support for sfz from the major conversion tool manufacturers is rumoured, it could be a lot of work to reprogram. This is more with regard to new libraries which could be programmed from scratch with sfz or whatever. In any case, special code would have to be written to stream audio from the net for any sampler to do what I suggest (serverside mixing, read below ;) ).



Even though you suggest that it shouldn't need too much bandwidth, I disagree. Even using a compression scheme, when you're streming a bunch of samples over the net, there are still large bandwidth issues. Where would the audio be cached when using a large precache setting?

On the client PC, in lossy format. The precached samples could be permanently stored on the users machine to obviate repeated downloading. I don't think it would take that long to precache, with modern broadband connections. Already some large multisample manufacturers are offering download options for purchase. You could even consider offering these precached samples as a public 'demo' for free distribution. This should ease the download burden for the manufacturer's server. Think about how large the precache is with many DFD based samplers anyway - up to 1 second each. Trans-internet latency is typically much less - 1/10th of a second or less. I wouldn't for a second suggest streaming off the server hard drive incidentally... To deal with high loads a huge amount of RAM on the server would be infinitely preferable.


If it is cached at the server, the server would need tons and tons of memory and then all of the audio for each sample would still need to be streamed as notes are played. You could easily use up more bandwidth than streaming a stereo mp3 (think of each note as a stream). If the audio is cached on the downloader's computer, well that is even worse because you must download a "precache" of every sample to your computer. Just starting it up would require huge bandwidth. This is just from a single user. Multiply this by multiple users.

No, all the notes would be mixed serverside, and streamed to the user in compressed format.


In regards to the rent-only model that you perhaps suggested, That opens up a whole new can of worms. How is there any way to control that the samples will not be resampled?

How is there any way to do this anyway? Watermarking? You could do this with the final lossless mix you send when rendering.



Anyway, it's nice to see some people thinking about this issue. Even though there may be unworkable ideas, people suggesting and coming up with different and inventive ideas will one day yield a good solution to this. I don't think that we're quite there yet. Solutions like this require creativity but perhaps also lots technical ingenuity too.

Just my .02
FV
I don't see my idea as unworkable at all. Feel free to prove me wrong however. I don't think it's technically that different from streaming from hard disc - there is a lag involved with that as well. OK, there is a compression and mixing stage prior to the 'streaming', but it's not THAT different, as I see it.

[Jordo]

I don't think it will work. What purpose would be pre-caching something on the client's side if the audio is getting streamed back to the user?

So what you are proposing is that everything gets processed on the server, then the audio is streamed back. The server receives the data, processes it, encodes it, then streams it back. Streaming would never work because in order to stream you need a buffer. Typical buffering of pre-compiled mp3 encoded files are somewhere 1-3 seconds, typical buffering in mp3 signals that encoded on-the-fly (such as internet radio stations) are 10-30 seconds. What you would be talking about is encoding/rendering on-the-fly. Caching anthing on the client side wouldn't work because the audio is being rendered on the server side.

Like i said speed is the problem here. DFD works good because it doesn't load the entire sample into ram, just the first second or so like you mentioned. A nice little hack because going to the Hard drive was too slow. Going through the internet is WAY slower then going to the hard drive! I haven't seen any applications that run efficiently over TCP/IP. Just too slow. Of course it's the future and it's where the technology is taking us, but I wouldn't hold your breath. :)

[griels]

I don't think it will work. What purpose would be pre-caching something on the client's side if the audio is getting streamed back to the user?

So what you are proposing is that everything gets processed on the server, then the audio is streamed back.

No I'm not. Reread my proposition carefully. The start of the samples are stored, decompressed and mixed clientside. The rest of the audio is mixed and compressed server side and streamed over the net. The stream is decompressed and mixed with the output of the sample start section to form the complete signal.



The server receives the data, processes it, encodes it, then streams it back. Streaming would never work because in order to stream you need a buffer. Typical buffering of pre-compiled mp3 encoded files are somewhere 1-3 seconds, typical buffering in mp3 signals that encoded on-the-fly (such as internet radio stations) are 10-30 seconds. What you would be talking about is encoding/rendering on-the-fly. Caching anthing on the client side wouldn't work because the audio is being rendered on the server side.

Like i said speed is the problem here. DFD works good because it doesn't load the entire sample into ram, just the first second or so like you mentioned. A nice little hack because going to the Hard drive was too slow. Going through the internet is WAY slower then going to the hard drive! I haven't seen any applications that run efficiently over TCP/IP. Just too slow. Of course it's the future and it's where the technology is taking us, but I wouldn't hold your breath. :)

Yes, the net is way slower than a HD. But you can use a lossy compression for real time use, then a lossless codec for offline rendering. Read again!

:)

[FV]

Hi,


Well, seeing as you can get a 100% quality rendering with my proposition, I see little to complain about.

The complaint would be as a result of your suggestion to "rent" the demo time. People would eventually compare it to testing out a synth in a music store (which is free and you can test it all day if you want) to "renting" time with a sample library in order to just demo it. That would be the complaint - not the ability to get a 100% quality render. The people who know that they definitely want that library would have no problem renting it. It's the ones who merely want to try it out to see if they like it or not.


Well, admittedly the horse has bolted from the stable door to some extent with the existing libraries. Although support for sfz from the major conversion tool manufacturers is rumoured, it could be a lot of work to reprogram.

I see this as being a little bit irrelevant as most *new* libs nowadays (not all) are Kontakt-based. The people from CDXtract and Translator are not legally allowed to write conversion routines for these (Kontakt) libraries because of the copy protection. The only thing would be if these conversion routines were written specifically for the sample lib developers in order to port to other platforms.


On the client PC, in lossy format. The precached samples could be permanently stored on the users machine to obviate repeated downloading. I don't think it would take that long to precache, with modern broadband connections.

Have you really calculated this out? This precache-ing would involve every single sample. If a library has 10,000 samples (I'm sure that QLSO has more) and you have a precache of 1 second (as you suggested), someone must download 10,000 seconds worth of samples for precache. Taking into account that a 5 minute stereo file is approx. 50 MB worth of .wav data and a decent compression scheme is about 10 % of that, you're looking at 5 MB of compressed data for 5 minutes of samples. That yields about 33 MB of compressed precache for one single library for one single user. Obviously, there would be more than one user at a single moment in time streaming more than one library. So that would not be the end of the calculations.

For one, I highly doubt that the developers want everyone (who has not bought the library but is only demo-ing it) to have a copy of even a portion of these samples on their hard drives. As well, the server requirements to have even as few as 20 users for, say, 10 of their libraries (space, streaming bandwidth, etc.), would probably be cost-prohibitive. I don't think that the above numbers are unrealistic and I would hazard a guess that they would actually be higher.


Already some large multisample manufacturers are offering download options for purchase.

Like who? Anyone with Gigabytes of downloadable samples (I mean a single library not multiple ones to add up to gigabytes). The last time I checked out Wizoo, they have up to roughly one CD's worth of downloadable samples. That's quite a bit but it's not the 3 GB, 10GB, and greater libs that you see around nowadays.


I wouldn't for a second suggest streaming off the server hard drive incidentally... To deal with high loads a huge amount of RAM on the server would be infinitely preferable.

To take an extreme example, how would a server be able to compress, mix, stream, and load up the ~70 GB of samples in QLSO Platinum? Single machines streaming direct off the hard drive (which is much quicker than the internet) can't handle the full Platinum package. Now take a small handful of users and small handful of smaller libraries (such as Hardcore Bass, PMI Bose, etc.) playing off of the server. It doesn't look that feasible to me as you wouldn't be able to load up that much memory onto a server. Plus, each instance of the instrument would need to be separately loaded in RAM in order to keep different sessions different. If you're talking about sharing the loaded samples, well, then you'd need completely new players which are coded in such a way that they are multi-client. Currently the bundled players always assume a single user.


No, all the notes would be mixed serverside, and streamed to the user in compressed format.

Unless I'm misunderstanding you, you're contradicting yourself here. Why would you need "precached" samples if the notes would be mixed serverside? You're also only considering one single library. Well, these developers have several libs and, in some cases, hundreds. The "precache" would be huge for all of those hundreds of libs.


I don't see my idea as unworkable at all. Feel free to prove me wrong however. I don't think it's technically that different from streaming from hard disc - there is a lag involved with that as well. OK, there is a compression and mixing stage prior to the 'streaming', but it's not THAT different, as I see it.

Sure it's different. You're forgetting throughput (which is quite a different concept from lag or latency). A hard disk can handle much more streams than a regular broadband connection on the internet. Perhaps what isn't that different is the concept of streaming itself. However, technically, it is different because you do have different restrictions and limitations due to the medium and transport. You also have the compression and mixing stage as well. These surely add more strain to the server as well. You've also got a bunch hard disk requirements to store all of the terabytes worth of data required to handle this streaming. If RAM, then the memory requirements are enormous.

I suggest that you approach one of the main sample lib developers and pitch this complete idea to them. It's not just on the technical side that I believe there are challenges but also on the financial side. These companies would need to acquire a bunch of new servers to specifically handle this in order to service the users who want to demo and most likely either a bigger "pipe" to the net or even a second "pipe" so that it wouldn't affect their online store. This all costs money (and servers don't cost the same as your typical $1500 PC) and I highly doubt that it would work out to a very low cost in order to provide this service.

You still view streaming via the internet and streaming from a hard disk as the same thing. They are not. The concept may be the same but a hard disk can deliver data much faster than a typical broadband connection. A hard disk's transfer rate is typically measured in (several) MB per second whereas a broadband connection is typically measured in KB per second. That is a huge difference IMHO.

I've said enough on this subject now. I feel that it is you who have not adequately provided proof that it will work. If you feel strongly about it, work out all the details and approach one of the sample lib developers who can bring it to fruition. I think that when you start to think multi-user environment with the multitude of different libs each developer has along with the server requirements, that boat starts to hold a lot less water.

You're free to think whatever you like (as am I). Either way, I hope that my comments have not offended - I'm merely stating my opinion. :)

FV

p.s. - sorry for the really long post everyone

[FV]

Hi,

Okay, just one more note.


No I'm not. Reread my proposition carefully. The start of the samples are stored, decompressed and mixed clientside. The rest of the audio is mixed and compressed server side and streamed over the net. The stream is decompressed and mixed with the output of the sample start section to form the complete signal.

What is doing the mixing? How is the precache being mixed with the rest of the audio and how is that buffered so that it is timed perfectly? I think that it is complex enough for someone to develop a player that does this with a hard drive and much, much more complex to develop some sort of internet player which will mix audio on the client in sync with streamed audio from the server in order to play back something so that it sounds like music.



Yes, the net is way slower than a HD. But you can use a lossy compression for real time use, then a lossless codec for offline rendering. Read again!

I have read again. :rolleyes: What I'm saying here is that this is so technically challenging, and possibly not even possible technically (again, look at the multi-user aspect of this - a developer would not implement this to service only one person at a time). Anyway, I agree with Jordo. Don't hold your breath. ;)

FV

[midphase]

This idea makes no sence and your reply to Michael even less!!!

_________________


Yeah! That's just the kind of positive reinforcement that we need more of!

Go Leo!

[Jordo]

Even on a single-user/server set-up this type of application would not work.

throughput, computing, streaming.

throughput -> not comparable to a local hard-drive

computing -> there's a reason why it takes time to 'render' an audio mixdown. there's a reason why it takes time to encode audio files.

streaming -> 'streaming' requires buffers. Typical DFD buffer -> measured in milliseconds. Typical buffer required for streaming over net -> measured in seconds.


You can't even run simple remote applications effeciently. You sure won't be able to run a processor/data intensive one.

Actually correction..... Get a team of computer scientists, spend a couple of decades in development. Write a new OS, along with optimized compilers, a new internet protocal, a more efficient DFD, and a new synth program optimized for streaming. Host the server on the Earth Simulator in Japan, and have the client plugged into to an internet backbone over multiple T3 lines, and you might be able to get by. :)

[griels]

Hi,

Okay, just one more note.



What is doing the mixing? How is the precache being mixed with the rest of the audio and how is that buffered so that it is timed perfectly? I think that it is complex enough for someone to develop a player that does this with a hard drive and much, much more complex to develop some sort of internet player which will mix audio on the client in sync with streamed audio from the server in order to play back something so that it sounds like music.



You have a fixed buffersize of precache. The audio streamed from the net is offset by the size of the precache - to sample accuracy. The client does the mixing. It synthesises only the start portions of the samples, the server synthesises and compresses the rest.

Also, I don't think 30MB of data is too much to download. I don't think the manufacturers would be too concerned about people having a lossily compressed set of the first split second or so of each of their samples either. Some gigasamples last minutes! In any case, you need only download the precached samples on demand... You don't need to load the WHOLE of QLSO to play one patch from it :)

I did think of one caveat with my idea though. The release phase. When a note off happens, there would be a lag until the server received notification. Nevertheless, 20ms lag isn't too bad for release phases, and lower latencies than even this have been seen in real time net applications.

Also, if you wanted to apply realtime CCs to the sound, e.g. CC11 or whatever, you would need an individually streamed audio channel for each MIDI channel or crossfading layer. Still, you should be able to get a fair few of these lossily compressed audio channels down a broadband connection.

Regarding conversion from Kontakt, CDxtract and EXSC2 can already convert from Kontakt, and I think it's slated for Translator. Obviously the soundware manufacturer will have an unencrypted version of their Kontakt library which can be read by these programs and converted into sfz format or whatever format I want the proposed player to read :)

[FV]

Hi,


Even on a single-user/server set-up this type of application would not work.

I was trying to make it more obvious by bringing in the multi-user aspect. ;)

FV

[FV]

Hi,


You have a fixed buffersize of precache. The audio streamed from the net is offset by the size of the precache - to sample accuracy.

You can't guarantee the speed at which the audio is streamed from the internet as it does not remain constant. Audio streamed from a hard drive is more consistent.


Also, I don't think 30MB of data is too much to download.

You are assuming one user again. This would need to be a multi-user system servicing multiple streams.


I don't think the manufacturers would be too concerned about people having a lossily compressed set of the first split second or so of each of their samples either. Some gigasamples last minutes! In any case, you need only download the precached samples on demand... You don't need to load the WHOLE of QLSO to play one patch from it :)

Have you asked any manufacturers if they would be concerned or not? Yes, you don't need to load the whole of QLSO to play one patch from it. However, it needs to be available (as does the other libs) in order to be on demand.


Also, if you wanted to apply realtime CCs to the sound, e.g. CC11 or whatever, you would need an individually streamed audio channel for each MIDI channel. Still, you should be able to get a fair few of these lossily compressed audio channels down a broadband connection.

How many? "Should" and "can" are two different things. Have you calculated what the requirements would be?

Anyway, no one has yet built such an application and I doubt anyone will in the near future. Perhaps it will come in time but, for now, it is not a matter of simply hacking Kontakt's DFD or hacking Gigasampler to make it stream in the manner you describe over the internet vs from a hard drive.


Regarding conversion from Kontakt, CDxtract and EXSC2 can already convert from Kontakt, and I think it's slated for Translator. Obviously the soundware manufacturer will have an unencrypted version of their Kontakt library which can be read by these programs and converted into sfz format or whatever format I want the proposed player to read :)

The makers of CDXtract and Translator (and any other conversion software) are restricted from allowing their conversion routines to work with the copy protected libraries such as QLSO, Hardcore Bass, Morphology, etc. If you're thinking that you're able to convert using one of these programs you will be sadly mistaken.

FV

[griels]

Hi,



You can't guarantee the speed at which the audio is streamed from the internet as it does not remain constant. Audio streamed from a hard drive is more consistent.

Just depends on your buffersize. If you have a large enough buffersize then you should be able to cover the typical peaks and troughs in trans-Internet latency, especially if you try to minimise the number of server hops, by having geographically close servers with strategically chosen network placement. Ideally you would use a subscribed route, but that would be dependent on the end-user ISP. Regarding the 10-30 second lags for on the fly MP3 streams, I can't understand the difference between that and streaming preencoded MP3 files. I can't see any reason for a fixed bitrate lossy codec to have high latency.



You are assuming one user again. This would need to be a multi-user system servicing multiple streams.

A one-time 30MB download per user doesn't seem too much PER USER. In any case, it would be much less because you could do it on a per patch basis... All cache data once stored on the client PC, would remain there unless deleted by the end user.



Have you asked any manufacturers if they would be concerned or not? Yes, you don't need to load the whole of QLSO to play one patch from it. However, it needs to be available (as does the other libs) in order to be on demand.

Yes, but a small delay whilst downloading the cached part of the patch would be acceptable I think. It's much less of a realtime requirement to change patches on the fly than to be able to play sounds on the fly :)



How many? "Should" and "can" are two different things. Have you calculated what the requirements would be?

A 0.5MB DSL connection can carry at least 3 128kbps usable quality Ogg Vorbis streams.
A 2MB DSL connection can carry 15 or so.


Anyway, no one has yet built such an application and I doubt anyone will in the near future. Perhaps it will come in time but, for now, it is not a matter of simply hacking Kontakt's DFD or hacking Gigasampler to make it stream in the manner you describe over the internet vs from a hard drive.

Indeed not... As only one stream per MIDI channel at most would be being streamed across the net, as opposed to one or more per note, and there is of course a decompression stage, and MIDI has to be sent out to the server.

But just because it hasn't been done, doesn't mean it can't. Many people would have said Gigasampler could never be done... Remember how troublesome the early versions were? :)




The makers of CDXtract and Translator (and any other conversion software) are restricted from allowing their conversion routines to work with the copy protected libraries such as QLSO, Hardcore Bass, Morphology, etc. If you're thinking that you're able to convert using one of these programs you will be sadly mistaken.

FV
I never said that! I said the soundware manufacturers, having in their possession an UNencrypted version of the libraries, would be able to use CDxtract or EXSC2 to convert Kontakt libs to another format.

OK.. I admit it.. I don't know all the ins and outs of this idea. But it's something I've had in mind for a long time, and I'm really curious to see if it would be possible, so I'm playing Devil's Advocate to an extent. :D

[FV]

so I'm playing Devil's Advocate to an extent. :D

I was beginning to envision you with horns ;) :D LOL

FV

[griels]

I was beginning to envision you with horns ;) :D LOL

FV

Hehe :D

Possibly the 'rental only' idea is a bit demonic :D

[sullivang]

Just by the way, I think I recall suggesting a very similar idea way back when Gigasampler was just being released - I wanted to have a bit of a tinker with it, and was having trouble finding a place that had it set up. So I proposed the idea of allowing it to be demoed remotely (as it turns out, I was extremely lucky - a music shop put me in touch with a very cooperative existing customer) I still don't think it's all that crazy an idea. (the pre-caching of the samples is introducing what I feel is unnecessary complexity, though, at least at the outset)

Greg.

[griels]

Just by the way, I think I recall suggesting a very similar idea way back when Gigasampler was just being released - I wanted to have a bit of a tinker with it, and was having trouble finding a place that had it set up. So I proposed the idea of allowing it to be demoed remotely (as it turns out, I was extremely lucky - a music shop put me in touch with a very cooperative existing customer) I still don't think it's all that crazy an idea. (the pre-caching of the samples is introducing what I feel is unnecessary complexity, though, at least at the outset)

Greg.

Sure, I think your idea is a good first step. A lossily compressed version of an FX Teleport like scheme sounds like a nice idea, so you could quickly browse presets and find the sounds you like. You could run it from your sequencer and it could be delay compensated with a buffer around the size of the typical peak network latency. And of course the results wouldn't be the same as using the original media, as it would be based on lossy compression. You could always charge a small fee to allow rendering using a lossless codec.