xml is a brilliant data exchange media but never an efficient way of storage. speed, management and size efficiency are less than optimal. this may not be critical when you have to deal with a few hundred records only, but let me propose the project should have a structure that can be extended to big multi-site data management / library options.
it is better to have only one storage method for everything, and this is the (probably open source) sql database. the routines are very cheap and fast, to accomplish this.
then you have perfect decoupling of workhorse routines and data interchange routines, and intrinsic low level management.
it would be wise to project a rich data model that reflects all known and desired parameters of sound font technology, and design the fetch/store routines in a way that they can be easily extended when the database is enhanced with additional fields/attributes. this is done with the help of a versatile data dictionary (i.e. meta level).
also, database stuctural management can be done well with OOP technologies.
new project: soundfont assembler
-
- KVRAF
- 8389 posts since 11 Apr, 2003 from back on the hillside again - but now with a garden!
I suggested xml rather than jeffs ascii files getting unwieldy.
I do agree about using some database tho', whether MYSQL, XBase, or some other technology; but only if this is going to be dealing with large numbers of samples (which it mightbe). An advantage of a RDBMS is that in the event of a corruption, most can self repair, but trying to repair an xml file can be a nightmare, especially if optimised into a single line...
DSP
I do agree about using some database tho', whether MYSQL, XBase, or some other technology; but only if this is going to be dealing with large numbers of samples (which it mightbe). An advantage of a RDBMS is that in the event of a corruption, most can self repair, but trying to repair an xml file can be a nightmare, especially if optimised into a single line...
DSP
-
- KVRian
- Topic Starter
- 500 posts since 13 Oct, 2004 from Durham, NC USA
-
- KVRian
- Topic Starter
- 500 posts since 13 Oct, 2004 from Durham, NC USA
I've continued to think about this project. To make my life easier and allow me to concentrate on the meat and potatoes, I've decided to implement it as a VST, using sfz format (for now) and sfz to play the samples. I'll start out using a host like Hermann's VSTHost, and if I need to make any host mods I can use the tiny host that comes with the SDK. I'll write in C++ for speed in the numeric algorithms.
I'm going to concentrate first on providing a GUI that makes it far easier to collect a good set of samples. I have several display modes in mind that will make it easy for the user to see how evenly covered the sample set is, to direct efforts to filling the gaps. Also to see (and hear) how well closely related samples match, such as the different velocities for a given note, and the different notes at a given velocity level.
The VST would record each sample as the user plays it, with the user's choice of whether to save each sample by default and reject by hitting the space bar or vice versa. It would be quickly processed to determine pitch and level, and update the GUI display. It would also update the sfz file using a relatively trivial mapping, allowing the user to play the notes.
But I'm afraid the last time I wrote GUI code was for SunWindows back in the late 80's! I'm going to need some help in the getting started department. Once I have a trivial prototype running it should be relatively easy to adapt it as necessary to suit my purposes.
For displays, I hope to include the following:
1) recording peak meter (of course!)
2) sample map, showing all collected samples in a square grid with level and note axes (pitch detection will be automatic). For level the user gets to choose peak or RMS (at any time). It'll probably be just a simple display with a box or dot lit if a sample exists for that section.
3) Envelope display showing multiple samples, either all the samples for a given note, or all the notes at a given velocity. This would be a staggered set of line graphs and would look like a surface plot if the samples are similar with trends. (No doubt there's a technical term for this kind of display, but I sure don't know it.)
4) Spectral display showing multiple samples as above, showing the spectral content of neighboring samples.
The purpose of #2 is to help get an even sampling to begin with. #3 and #4 help to find clinkers and discontinuities between related samples. They'll also help identify when samples need to be spaced closer together (e.g., for Rhodes, you need more samples in the high velocity range, because tone changes more dramatically with velocity at high velocities.)
Originally I assumed that I'd have a display mode, one of 2,3, or 4 above, but it would probably be better to let the user create as many views as desired, based on screen room and CPU power.
If anyone would be willing to give me a leg up with getting this kind of VST GUI started, I'd really appreciate it!
Oh, display #2 would also be a sample browser; by clicking on any spot on the graph you'd select a sample and data for that sample would be shown along with the option to delete it or just unmap it for the time being.
One of the things I'd like the GUI to do is to encourage the recording of LOTS of samples. Subsequent mapping steps would be provided to automatically trim the sample set down to a manageable size, when that's desired, for a given mapping. Without deleting the actual samples, of course.
Thanks,
Jeff
I'm going to concentrate first on providing a GUI that makes it far easier to collect a good set of samples. I have several display modes in mind that will make it easy for the user to see how evenly covered the sample set is, to direct efforts to filling the gaps. Also to see (and hear) how well closely related samples match, such as the different velocities for a given note, and the different notes at a given velocity level.
The VST would record each sample as the user plays it, with the user's choice of whether to save each sample by default and reject by hitting the space bar or vice versa. It would be quickly processed to determine pitch and level, and update the GUI display. It would also update the sfz file using a relatively trivial mapping, allowing the user to play the notes.
But I'm afraid the last time I wrote GUI code was for SunWindows back in the late 80's! I'm going to need some help in the getting started department. Once I have a trivial prototype running it should be relatively easy to adapt it as necessary to suit my purposes.
For displays, I hope to include the following:
1) recording peak meter (of course!)
2) sample map, showing all collected samples in a square grid with level and note axes (pitch detection will be automatic). For level the user gets to choose peak or RMS (at any time). It'll probably be just a simple display with a box or dot lit if a sample exists for that section.
3) Envelope display showing multiple samples, either all the samples for a given note, or all the notes at a given velocity. This would be a staggered set of line graphs and would look like a surface plot if the samples are similar with trends. (No doubt there's a technical term for this kind of display, but I sure don't know it.)
4) Spectral display showing multiple samples as above, showing the spectral content of neighboring samples.
The purpose of #2 is to help get an even sampling to begin with. #3 and #4 help to find clinkers and discontinuities between related samples. They'll also help identify when samples need to be spaced closer together (e.g., for Rhodes, you need more samples in the high velocity range, because tone changes more dramatically with velocity at high velocities.)
Originally I assumed that I'd have a display mode, one of 2,3, or 4 above, but it would probably be better to let the user create as many views as desired, based on screen room and CPU power.
If anyone would be willing to give me a leg up with getting this kind of VST GUI started, I'd really appreciate it!
Oh, display #2 would also be a sample browser; by clicking on any spot on the graph you'd select a sample and data for that sample would be shown along with the option to delete it or just unmap it for the time being.
One of the things I'd like the GUI to do is to encourage the recording of LOTS of samples. Subsequent mapping steps would be provided to automatically trim the sample set down to a manageable size, when that's desired, for a given mapping. Without deleting the actual samples, of course.
Thanks,
Jeff
-
- KVRian
- Topic Starter
- 500 posts since 13 Oct, 2004 from Durham, NC USA
Oh, concerning the sampler format, I'll hide all that behind an OO API and code it in abstract terms. Then, if I get any help to make that plugin-izable, I'd be happy to do it, so different formats could be supported.