< Back to IRCAM Forum

File name and extension in synthesize

OMChroma
#1

Hello,

in our class, multiple users (including myself) noticed this problem: when using the synthesize object, adding the keyword :name, giving a “name.extension” string, it will not take the .extension as extension, but name the sound file as “name.extension.aiff”.

This leads to the paradox situation:

  1. changing the audio file format in the audio preferences to .WAV
  2. changing the CSound command line from -A to -W
  3. giving a “filename.wav” in the keyword :name of synthesize
    will lead to “filename.wav.aiff” result.

Still works, recognised (i.e. by Audiosculpt) as a .WAV file. Nevertheless quite irritating, i.e. in the case of generating sound files in a omloop with some auto-name rules.

(Using OM 6.15, OMChroma 5.02, MacOS 10.13.)

Thanks!
Marco

#2

Dear Marco,

Did some basic tests for the moment:
Using just a simple synthesize without key options and with these settings:
1- OM Audio prefs Default Audio format = WAV
2 - the -A flag for Csound (for aiff format)
So the outputed file from synthesize IS a WAV and the extension is written as an aiff. So the OM Audio pref apparently overrides the Csound flag and we have a faulty extension. Since i tested it on linux this is also bad, because it won’t output a sound using SOUND object because of this faulty extension.
So will investigate further, because synthesize is used by mostly all audio/synth libs and functions. And We will see what is the best to do. I propose these scenarios;
1- leave the master format of Om pref and correct the Csound output extension
2- Whenever Csound synthesis is involved, the cs audio flag overrides the om audio pref and the correct extension is written

Which one to choose? (personally #2) but should also see with other synthesize usage

Best
K

1 Like
#3

Dear Marco,

OM Audio prefs when using csound and/or chroma should comply with each others:

audiopref csound flags
WAV -> -W
AIFF -> -A

And if csound-synth is used, the extension should also explicitly be in accordance with the om settings in the preferences panel (audio prefs and csound external options).

Now if you need to normalize EVEN when the -N flag is in the csound command line options it will not normalize unless you set the normalization with Csound in omaudio prefs.
Seems that they are mandatory.

The bug format comes when omaudio pref and csound format flag are not compliant with each other, and when normalization is done with om audio internal normalization.

Maybe this all should be reconsidered however, if the above are obsereved, this will not be a problem.

By the way here is a small fix to put in the patches folder of OM, waiting for a new release of OMChroma. (yes there was a small small bug regarding the default sound file format in the chroma library).

omchroma_patch301119.lisp (6.0 KB)

1 Like
#4

Dear Karim,

very clear, thank you very much!

Best,
Marco