|
|
Post by guydenruyter on Jul 29, 2007 8:07:43 GMT
Not sure if audacity is best suited... I thought it was an excellent audio editor but not really a sample editor (allowing to specify zones, layers, root key etc).
|
|
|
|
Post by gwenhwyfaer on Jul 29, 2007 10:42:34 GMT
Well, there's a free soundfont editor out there too, Smurf (or its successor, Swami); I guess that could be altered to output Fusion banks. However, I still think a command-line filter that silently converts Soundfonts into Fusion banks would be more useful; it's a lot easier to add a filter to a GUI-based program than it is to try and make a huge monolithic program do things in batch mode. |
|
|
|
Post by guydenruyter on Jul 29, 2007 11:48:54 GMT
Command-line tool would be useful too for batch conversions, indeed. The GUI tool could then just simply invoke this tool as a post-script.
|
|
ray
Junior Member
Posts: 86
|
Post by ray on Jul 29, 2007 13:22:27 GMT
Hi guys, I'm jook from "the other place". I had no idea the conversation has moved over here or that gwen had made some further progress when I recently posted some new observations recently. That was some clever thinking there, on working out "neno"="none", and "amtt"="ttam"! That makes it much clearer as to what was happening with the files I was playing with. RE: "is it useful to develop this despite Fusion Converter", I can think of one reason. There is no option to select the compression method within Fusion Converter at the moment. So that I can't load a 150MB program (converted from Kontakt to S5000, then imported into Fusion Converter) I have in my 64MB stock Fusion. I think it would be great if I can turn on TTA compression on demand, and shrink sample programs as we see fit. At the moment, it seems to be entirely up to the Fusion Converter to decide when to use TTA, which seems to only use it when importing from 24bit samples at the moment. |
|
|
|
Post by guydenruyter on Jul 29, 2007 13:55:04 GMT
Reason good enough! Let's go on analysing the sample and program formats  |
|
|
|
Post by gwenhwyfaer on Jul 29, 2007 18:58:30 GMT
One caution - we don't know yet whether the Fusion expands samples on-the-fly or at load time; if the latter (which I suspect it is), then it doesn't matter how small the sample is when compressed, it can never be larger than 64Mb uncompressed.
|
|
|
|
Post by guydenruyter on Jul 29, 2007 20:26:32 GMT
That would be a bummer - but then, why would this be designed that way in these days of cheap storage?
|
|
|
|
Post by gwenhwyfaer on Jul 29, 2007 22:01:03 GMT
Well, in fairness, there's no reason to compress samples at all on a 40Gb hard drive. However, if you want to fit a 120Mb sample library into a 64Mb Flash ROM (remembering, of course, that according to the Keyboard interview with the team, the hard drive was a relatively late arrival to the Fusion's feature list) it's quite a good idea to compress them; even with a hard drive, if you can store samples in a compressed form and then uncompress them as they're loading, you can halve the sample load time; and processing time isn't so cheap, at least in signal processing terms, and playing back compressed samples is a lot more computationally expensive than uncompressed ones.
|
|
ray
Junior Member
Posts: 86
|
Post by ray on Jul 30, 2007 1:17:06 GMT
Good point. while I really hope that isn't the case, as I was going to start raving about the fact that the relatively small amount of RAM available on the Fusion (even when fully expanded) is not so bad when we have the ability to use losslessly compressed samples, ... I am actually suspecting the latter as well, since lossless decoding, on the fly, and for such high polyphony would require a lot of CPU. Something that might even be beyond the task of your Intel Core Duo computers (well, depending on the compression scheme I guess). I can hold out on the hope that TTA is especially good for decoding with low CPU usage though, and that it is actually possible ... that would be a truely impressive feature and a possible first in the hardware and software sampler world AFAIK. The most straight-forward way to test this would be to attempt loading in a compressed AFS that is just below 64 MB. Has anyone successfully created a compressed AFS/program (ie: "ttam") of their own? Or are the only compressed programs available the HollowSun and Alesis provided samples? Are Steve and co. allowed to tell us how they created their sample? Or are they completely restricted by NDAs ...  |
|
|
|
Post by gwenhwyfaer on Jul 30, 2007 4:05:43 GMT
Well, one way to accomplish that is to have a look at the individual samples on the hard disk, isolate the ones which are compressed, and then combine them into multisamples (or drumkits, come to think of it) more or less randomly until you run out of space. Then see how much space those samples take up...
|
|
Mr_Fusion.jpg)
