I discovered today while researching a non Bose product that some manufacturers are supplying their EASE speaker data in a GLL format. This downloads as a single file rather than the multiple files that I usually see in their data.
If I copy it into the speaker data folder in Modeler to use to evaluate the speaker coverage, Modeler does not recognize it (it does not show up in the speaker menu). Is there something that I am doing wrong? If not, are we working on a process to be able to use these files in Modeler in the future?
good questions. Complex answer, though. I’ll try my best to give some answers and likely, Rob will chime in as well. So, here’s some info regarding the more technical side of the .GLL:
GLL stands for Generic Loudspeaker Library and is promoted by AFMG (the authors of EASE) as their preferred loudspeaker format. Although several papers have been authored, e.g. at AES, the format itself is proprietary and used exclusively by EASE and other tools from AFMG. GLL data can be viewed using a free viewer, authors of GLL speaker files need a full EASE version that comes with ‘Speaker Lab’, a tool to assemble such speaker files. Modeler is unable to read .GLL data, same applies to the older .DLL data format used in EASE. More information about the GLL can be found e.g. in this whitepaper.
As you report, one difference to the old EASE speaker files is that it consists of one file only and no set of files is required to read balloons as well as associated data like wireframes, isolines, etc.. But the main difference is that the old .spk format could only describe a single balloon. Instead, the GLL allows to assemble a speaker, a cluster or a line array from many individual components. These could be woofers, mid or HF drivers or multiple cabinets of a line array or even all things together. In this regard, the GLL is similar to our .spm format which is also storing multiple balloons, if required.
One thing the GLL does that we don’t do with .spm files is the ability to assemble a complex array from components. We use array tools in Modeler for that purpose. In this regard, the GLL can be programmed by the speaker manufacturer to follow certain mechanical constraints upon assembly. It may also select appropriate EQ etc. The manufacturer can also hide proprietary signal processing inside the GLL, that’s why it is so widely used for steerable arrays. Basically, the GLL serves as ‘balloon-calculator’ that is called from within EASE during predictions, just as the older DLL’s. EASE says, my sample is here or there and then the GLL returns data for that location in space re: the origin of the array.
From users of EASE, we hear that working with GLL’s is on one hand very flexible and accurate (it also stores phase data), but it can also be cumbersome and slow since every time you want to adjust an array (e.g. re-aim elements) you need to open this GLL (potentially, all witihn a model !), make your adjustments and return to EASE.
Having said this, any implementation of the GLL format into Modeler is technically very complex and would require interface software written for us by AMFG. Alternatives exist in the form of the new v2 CLF 2 format and we are constantly discussing how we could bring competitive arrays into Modeler.
So far for today, let me know in case you have any further questions.
Thanks as always for your assistance. I was reminded in our Friday conference call that this had been discussed previously during one of our trainings and although I remembered the conversation, I had forgotten its association to the GLL format. Your post made the entire issue more clear to me however and the link to the white paper was an added bonus. A crystal clear answer that even a misplaced live sound guy like me could understand.
Once again, I am reminded how fortunate I am to have you as a resource.
Thomas makes a number of very good points in the above post. I'd like to elaborate on a few items.
As Thomas mentions the GLL format was promoted through AES as a new standard for loudspeaker data modeling, but has become a proprietary format specifically for AFMG. However, the methods used to describe the data and performance of a loudspeaker or array are used by a number of modeling tools. As you know within Modeler we use a format called .spm, and support .clf.
CLF is a format promoted by CATT Acoustic and the CLF group, which we contribute to. Recently CLF introduced a new format, CLF2 which incorporates a description of the loudspeaker's phase, among other improvements. We will be supporting this new format within Modeler at some point in the future.
As Thomas mentions when working with GLL/DLL in your designs it is like working with two programs simultaneously. You place the "device" in your model, and then must invoke the GLL interface to define its aiming, configuration, orientation, etc. The GLL then calculates the response of the device and passes this information to EASE.
In the case of .spm, like GLL, we also include an acoustic description, (magnitude and phase), of one or more drivers within the device. This description includes their physical and electrical relationships to each other. In the case of a single RoomMatch module there are four unique sets of acoustic data. Once the module is placed in the model all predictions are based on the discrete time offset (path length differences between the source and listener), as well as the magnitude/phase data for each acoustic source. This method is used in the case of a single RM module, or if it is a RM array. We believe that this delivers a highly accurate description of the product's performance.
The data contained with .spm is the same, in concept, but there are two advantages with this approach 1) the data is encoded in such a way as to deliver highly accurate, computationally efficient performance, and 2) everything is integrated into the model/design environment. Allowing you, the designer, to see changes in performance in real time as you work through design options (change the array, immediately see the result).
let me give a little bit more detail on Rob’s post above, I hope this will answer your question.
Historically, there have been two version of the CLF data format: CLF ‘Type 1’ and CLF ‘Type 2’. They have also been termed ‘CLF1’ and ‘CLF2’. The respective file extensions are ‘.cf1’ and ‘.cf2’. The first format is in octave-band resolution and has balloon data with 10° resolution. ‘.cf2’ is third-octave bands and 5°. Both formats contain magnitude-data only and both can – with a few exceptions - be read by Modeler using the appropriate hardware key.
In order to be precise about the terminology, what Rob referred to is termed ‘CLF2 v2’ in CLF notation. As said, this format also includes phase information and allows for special signal processing. Modeler does currently not support reading CLF2 v2 data.
Let us know if you need any additional information.