geezer
February 7th, 2004, 01:54 PM
Alright-
In response to the admin request in another thread, I will, once again, talk about some simple and very limited steps needed to continue to use Microeditor in the modern environment.....I would like to note that none of the questions I am raising are new. All statements can be found in threads from at least 2 to 3 years ago, and probably a bit further back than that.
However, since we have the admin's attention, I am going to state my particular views on the subject, and ask for others to chime in after me.
Since the admin is raising the issue of cost, I will arrange the solutions below in order of cost (least to most, in my opinion), and will indicate why I think at least 2 of the solutions should be very inexpensive......
File sharing, which is all I am really talking about, has always been my approach to low-cost compatability for MTU, in the face of zero money for serious feature development.
FILE SHARING SOLUTIONS:
1)32 BIT FILE SHARING (virtually free from cost)- It is my understanding that most other, modern native programs will open an .SF file as a "raw" 32bit floating point file......This is a done deal. These programs alll work natively in this format, and will save in this format. All that needs to happen now is to nail down what has to be done in the file header to bring it back into Microeditor.....Kind of a no-brainer, eh?
2)24 BIT WAV FILE SUPPORT (fairly low cost, I would think)....I don't think it should be hard to figure out the specs for these, either. Allowing Microeditor to read and write 24 bit Wav files would make it instantly compatible with everything else.
3)BROADCAST WAV FILE SUPPORT (don't understand how hard the programming, and thus the cost, for this would be)- This could happen on at least 2 different levels: a)simple recognition and use of files without using (or losing) any of the embedded (i.e.- time code) data. b)implentation of the time code data in time coded projects.........I put in a good amount of time to send MTU some BroadcastWav files 2 years ago, with no response. I don't know what that means.
.....All 3 of these solutions above involve code that is already existent to some extent in MTU. None of them address the other issue that I don't see MTU ever addressing: higher sampling rates.....this is the long term compatability issue, but, even though I have begun working at 96k, I don't think it will be deadly for MTU for another 4 years or so.
Anyway, feel free to chime in.
In response to the admin request in another thread, I will, once again, talk about some simple and very limited steps needed to continue to use Microeditor in the modern environment.....I would like to note that none of the questions I am raising are new. All statements can be found in threads from at least 2 to 3 years ago, and probably a bit further back than that.
However, since we have the admin's attention, I am going to state my particular views on the subject, and ask for others to chime in after me.
Since the admin is raising the issue of cost, I will arrange the solutions below in order of cost (least to most, in my opinion), and will indicate why I think at least 2 of the solutions should be very inexpensive......
File sharing, which is all I am really talking about, has always been my approach to low-cost compatability for MTU, in the face of zero money for serious feature development.
FILE SHARING SOLUTIONS:
1)32 BIT FILE SHARING (virtually free from cost)- It is my understanding that most other, modern native programs will open an .SF file as a "raw" 32bit floating point file......This is a done deal. These programs alll work natively in this format, and will save in this format. All that needs to happen now is to nail down what has to be done in the file header to bring it back into Microeditor.....Kind of a no-brainer, eh?
2)24 BIT WAV FILE SUPPORT (fairly low cost, I would think)....I don't think it should be hard to figure out the specs for these, either. Allowing Microeditor to read and write 24 bit Wav files would make it instantly compatible with everything else.
3)BROADCAST WAV FILE SUPPORT (don't understand how hard the programming, and thus the cost, for this would be)- This could happen on at least 2 different levels: a)simple recognition and use of files without using (or losing) any of the embedded (i.e.- time code) data. b)implentation of the time code data in time coded projects.........I put in a good amount of time to send MTU some BroadcastWav files 2 years ago, with no response. I don't know what that means.
.....All 3 of these solutions above involve code that is already existent to some extent in MTU. None of them address the other issue that I don't see MTU ever addressing: higher sampling rates.....this is the long term compatability issue, but, even though I have begun working at 96k, I don't think it will be deadly for MTU for another 4 years or so.
Anyway, feel free to chime in.