![]() Tol1 = 1e-6, tol2 = 1e-6, algorithm = 'autocorrelation'): There's an entire community willing to help.ĭef sound_to_lpc( sound, order = 16, window = 0.025, step = 0.005, preemph = 50.0, But in any case, this is not something that should be done by a single person. It will be a lot of work, that's for sure. All I'm suggesting is that we seize this opportunity to create a more streamlined interface for its library with developers in mind. The Praat interface is married to its past because of backwards compatibility. If the library is successful, then we'd see users coming to it that have never used the Praat GUI before, and I can imagine them scratching their heads as to why they need to use commands with spaces, parentheses, numbers, ampersands and trailing ellipses in their names. I'm talking about designing an API for the Praat library which is powerful and versatile enough to (at least) power the GUI (that's what I meant before), but as simple and concise as it can be so that it is easy to use. So no one is talking about making those packages "unavailable". each of which will have an API that will likely (hopefully!) have fewer than 8000 "commands" (whatever those may be in that particular case). Many of those "commands" will be available as part of one of those additional libraries. The same with Python.Īnd in both cases we are also talking about languages that are extendible by loading additional libraries (or modules, or packages, or however they are called). There's technically no limit to the number of those that can be made available. R has no notion of "command", it uses functions which can be created and redefined at runtime. Result = praat.do_array2 (command, args) (numpy matrix result) Result = praat.do_array1 (command, args) (numpy vector result) Result = praat.do_str (command, args) (string result) Result = praat.do (command, args ) (numeric result) OK, the Python API will look more or less like this (assuming there is a single Praat object): (Yes, I know that there is one exception to full separation in the code good for you if you can find it.) For instance, the code can be compiled without GUI, or without graphics, or without interface files, and everything else still works for instance, Sound.cpp contains a function Sound_draw, but that function does not require any graphics implementation to be present. As for your "clearer, better organised code" idea, the code as it is now has been optimized for clarity and organization already. By the way, the "single exposed command" you mention is already there: if there are menu commands "Draw" and "To PointProcess" for a Sound object, this means that there are C++ functions Sound_draw and Sound_to_PointProcess with the same arguments. In my proposal (it is not new), the Praat manual as it is would automatically be the manual for the API, and the existing menus would define the available functions. Praat has more than 8000 commands, and it would be a hellish job to convert all of them to short names (by hand, given your examples), and to document the relation. If the interface is not good, chances are people will not want to use it.Īlong the lines of Python's subprocess.call command: Libraries are as good as their APIs, so I think some work should be put into the design of a good one. I guess it depends on how much extra work an API would be. Not to mention that it would also provide an example of how to use it. That would give a good indication of whether its API was sufficient or not, and I think it would ultimately lead to clearer, better organised code. I think what would be ideal would be to dogfood the library with the Praat GUI. It's probably better to just have a limited API that can call exactly the same Praat commands that a Praat script can call, namely all menu commands available in the Objects window and the Picture window Then again, having everything in the same library would be infinitely better than not having any library at all. Couldn't those be in, say, libpraatshell, libpraatpicture and libpraatcore? That would solve that problem, and allow people to better tailor what they need. The shell is different from the plotting features, which are different from the commands from the objects and editor windows. Such a library would contain lots of stuff that you wouldn't need for a web service, for instanceĬouldn't we just break those into smaller ones? Praat is a complex beast with many different parts that are not necessarily related. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |