On Tuesday 11 November 2003 05:00 am, Udaya Kumar.R wrote: The short answer is, these specs aren't going to sound good, no matter how you get there. If you take a 16-bit, 48000 signal, and convert it to 8-bit 7200, you are throwing away 92.5% of your data. The result is bound to be a little noisy ;) I don't know exactly what it is that you are recording, but you might be able to improve your results slightly by: 1. Making sure you input signal level is as hot as it can get without clipping 2. Recording at the highest quality level supported by your hardware 3. Running the sound through a compressor or (better yet) look-ahead limiter 4. Normalizing the sound 5. Converting down to your final format I'm not familiar with the programs you're using. If you can't find "Compressor" and "Normalize" in your application, you might want to give Audacity a try: http://audacity.sourceforge.net/ Also, if you've never worked with a compressor before, you might find the following helpful: http://www.harmony-central.com/Effects/Articles/Compression/ Good luck! |) |)enji

Hello Derek, This is something that has been on my TODO list for tapiir for a long while... I think MIDI control would be nice, but it's 7-bit data range is a bit of a problem. Of course it is possible to work around that with multiple controls per value, but for from ideal. What other possibilities does PD offer? Maybe writing to a named pipe (fifo)? I could easily implement the input part in tapiir. Or maybe it would make more sense to write an PD object that incapsulates tapiir? I do not know however, if it is possible to use a non-PD graphical UI with a PD object. Maarten

Hi Maarten, and thanks for your reply. I am glad that a higher level of control is on the agenda for Tapiir, as I only think it would expand its functionality immensely. I am xposting to the PD list, where others might have a great interest in this... Maarten De Boer wrote: You are correct about MIDI... outdated stuff. Espc with the sample precision of the delays which Tapiir has. A fifo could be an option, I would have to ask on the PD list what the best way to interact with that would be. By default, PD prints to stderr, if that helps you at all... However, some solutions in PD and its close friends exist already. I would advise you to look at netsend [native PD object, udp or tcp flavors] and OSC [Open Sound Control: cross-platform, 3rd party protocol for sharing data implemented in CuBase, PD, Max/MSP, Reaktor and others]. I think espcially OSC would be *very* interesting for Tapiir, considering how easy it may become to use Linux sound apps under Mac OS X in the future. The way that VST and LADSPA plugins have been implemented in PD [via plugin~ external object] is always without their native GUIs. Named or numbered messages containing the control data are sent to a single inlet of the object, allowing PD users to make whatever kind of interface they like. If you want to go this route, perhaps somebody on the PD list could point you to some good resources on creating externals. One by IOhannes Zmoelnig is here: http://iem.kug.ac.at/pd/externals-HOWTO/ Best wishes, D. derek wrote: -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 169: "Use filters"

maarten, Quoting Maarten De Boer <mdeboer(a)iua.upf.es>es>: Netsend and netreceive are paired objects in PD, usually used for connecting remote machines, and capable of transporting TCP or UDP messages. Netsend takes an message of "connect hostname portnumber", which I suppose could be made a localhost and a port in Tapiir. I still think it would be worthwhile to use OSC, as it is a wider-used format, allowing communications with many more apps than PD. But it could [not sure here] be a bit more work. Any OSC developers here-abouts? Not necessarily. What I hope is to be able to automate the large number of controls in Tapiir, or to be able to change presets [.mdt files] very quickly during performance. No GUI is really required for this if I figure out the right control numbers or make my own presets. In such a case, a PD object would be quite fine ;-) best, D. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 49: "Display your talent"

I would also second Fernando's encouragement to use OSC since that way more inter-app communication will be possible, something that we really need amidst all these diverse software packages that unfortunately often offer very little interoperability. Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico Lopez-Lezcano Mac be wider-used [not against