opendaff-users — Mailinglist for users of OpenDAFF

[Opendaff-users] Updated license for OpenDAFF

[Frank W. <Fra...@ak...>]

Dear OpenDAFF users,

we decided to change the license of OpenDAFF, motivated by the requests 
of users to statically link DAFF as part of their applications.
The LGPL v3 license, under which OpenDAFF is distributed, permits 
linking an application dynamically to the DAFF library, without 
enforcing the GPL/LGPL to the application itself.

For static linking the situation is different.
Application developers do not need to provide the source code of their 
application when using DAFF, but they must make at least the link 
process interchangable.
This would mean, that they for instance need to provide compiled object 
files of their application, so that users can relink the application to 
compatible versions of OpenDAFF.

This can become a headache when OpenDAFF shall be used within payed apps 
on mobile devices.
Apple for example, do not want dynamic linking in their AppStore apps.

It is our interest to support these use cases.
We want to see OpenDAFF as part of apps as well.
Therefore we modified the library version.
It is still provided under the terms of the LGPL v3.
But we have added a special linking exception which solves the above 
stated difficulties.
The following item was appended to the license (COPYING.LESSER).

----------------------------------------------
   7. Special Exceptions.

As a special exception to the GNU Lesser General Public License version 3,
you may convey to a third party an executable file from a Combined Work
that links, statically or dynamically, portions of this Library in the
executable file, conveying the Minimal Corresponding Source but without the
need to convey the Corresponding Application Code under section 4d0 of the
GNU Lesser General Public License, so long as you are using an unmodified
publicly distributed version of the Library. This exception does not
invalidate any other reasons why the executable file might be covered by
the GNU Lesser General Public License or the GNU General Public License.
----------------------------------------------


If you have any questions, feel free to contact me.

Best regards,

Frank Wefers


-- 
________________________________________________


    Dipl.-Inform. Frank Wefers
    Virtual Acoustics Workgroup

    Institut of Technical Acoustics (ITA)
    RWTH Aachen
    Neustraße 50
    D-52066 Aachen

    Phone  +49 (0) 241 80 97989
    Fax    +49 (0) 241 80 92214
    Mail   Fra...@ak...
    Web    https://www.akustik.rwth-aachen.de

________________________________________________

Re: [Opendaff-users] Compiling OpenDAFF

[Jonas S. <st...@ak...>]

Hi Jorgos,

Are you using the trunk or the branches/dev version of the daff library 
and utils? I strongly recommend to use the delevoper branch since no 
changes have been merged into trunk for a while.
The URL is: 
https://opendaff.svn.sourceforge.net/svnroot/opendaff/branches/dev/
You will find a file called COMPILING.txt, follow the instruction steps 
and you should be able to build the library. It is essential to define 
the platform first, so do not forget to

export BUILD_PLATFORM=Linux

After that you should be able to create the lib with command

make lib

I think you will encounter problems with the utils under Linux, but give 
it a try:

make utils

I definitely was able to do so a couple of month ago, but I can remember 
that some patching to the Makefiles was necessary.
There are serious thoughts on switching to a cmake configuration amongst 
all developers, means if you are not successfull you may want to wait a 
bit and give OpenDAFF another shot once a stable version is released.

Kind regards,
Jonas

Am 23.01.2012 12:09, schrieb Jorgos Estrella:
> Hi,
>
> i'd like to compile openDAFF in linux but when i try "make" i become:
>
> make: *** No targets specified and no makefile found.  Stop.
>
> or make lib:
>
> make: *** No rule to make target `lib'.  Stop.
>
> What am i missing?
> cheers
>
> Jorgos

[Opendaff-users] Errors when building OpenDAFF-MEX on Windows using Matlab

[Frank W. <Fra...@ak...>]

Dear DAFF users,

we recently discovered a flaw that can occur when building the OpenDAFF 
Matlab Extension on Windows. When running the
'make.' script in opendaff/bindings/matlab, the output can be:
_________________________________________________________________

Building OpenDAFF Matlab extension using 'Microsoft Visual C++ 2005 SP1'...

mex: Invalid command-line option

mex: Data: unknown option

??? Error using ==>  make at 80

Building OpenDAFF Matlab extension failed
_________________________________________________________________

There is nothing wrong with OpenDAFF. The error happens when you have 
Perl installed on your system (e.g. ActivePerl or Cygwin Perl) and the 
binary directory of this Perl installation is in the system path, BEFORE 
the Matlab binary path. What you need to do in order to fix the error is 
to put the Matlab director(ies) in the system path BEFORE any Perl path 
in your system path. Then is should work perfectly.


Best regards,

Frank

Re: [Opendaff-users] Build-problems with Linux.

[Matthias G. <mat...@gm...>]

Dear Frank, Dear list.

Thanks Frank for your answer and for fixing the errors and thanks also
to Jonas for his off-list answer.
And thanks to all OpenDAFF developers, you're doing a great job!

On Sun, Oct 2, 2011 at 20:02, Frank Wefers
<Fra...@ak...> wrote:

[...]

>> - Missing CPU detection
>>
>> Makefile.Linux, line 41:
>> CXX_FLAGS    := -Wall -march=i686
>>
> This was something written quick and fast, without thinking about other
> platforms. We changed it so -mtune=generic which determines the best
> platform optimizations automatically.

I don't know much about this, but will it really be the "best optimizations"?
Wouldn't "-mtune=native" (or the same thing with -march) give better
optimizations?
Anyway, for now I'm not really interested in the best possible
optimization, I just want to get it to work.

[...]

I tried it again after the most recent changes in the dev branch (r134):

Compilation of the library works now without problems.

Compilation of the DAFFTool also works smoothly. And now it doesn't
crash when I run "dafftool info ...", that's great!

Old DAFF files produce an error (as expected):

Error: File format version unsupported

It would be nice, however, to see which version the file actually has,
is this possible?

The compilation of the DAFFViewer is still not working.

At least I managed to install libvtk version 5.4.2, so the
requirements should be fulfilled.
BTW, the Debian package is called libvtk5-dev, not libvtk-dev.

In utils/DAFFViewer/Makefile, I had to add /usr/include/vtk-5.4 to the
INCLUDE_DIR.

Then there is an error:

[...]/3rdparty/FXVTK2/src/FXVTK2Directivity.cpp|105| error: no
matching function for call to ‘vtkCellArray::InsertNextCell(int, int
[3])’
/usr/include/vtk-5.4/vtkCellArray.h|292| note: candidates are:
vtkIdType vtkCellArray::InsertNextCell(vtkCell*)
/usr/include/vtk-5.4/vtkCellArray.h|235| note: vtkIdType
vtkCellArray::InsertNextCell(vtkIdType, const vtkIdType*)
/usr/include/vtk-5.4/vtkCellArray.h|253| note: vtkIdType
vtkCellArray::InsertNextCell(vtkIdList*)
/usr/include/vtk-5.4/vtkCellArray.h|271| note: vtkIdType
vtkCellArray::InsertNextCell(int)

So I tried it with libvtk-5.6 which is available in Debian testing
(wheezy), but this produces the same error.
Sadly, libvtk-5.2 is not available in Debian.
I could install version 5.2 from source, but maybe there is an easier solution?

I also tried the "solution" of removing the offending lines.
Afterwards, I was able to compile and run the program, I could also
open DAFF files, but there was no display (except the axes) in the 3D
view.
But still, everything else seemed to work.

cheers,
Matthias

Re: [Opendaff-users] Request for deletion of confusing old dev folder

[Jonas S. <st...@ak...>]

Thank you very much.

Am 03.10.2011 02:09, schrieb Frank Wefers:
> Dear DAFF users,
> Dear Jonas,
>
> toclearify things: /dev was created accidentially a year ago when
> checking in wrongly. The correct dev-branch is /branches/dev. I saw this
> mess before and had removed the false dev-branch quite a time ago and I
> am wondering that it is still/again there. All changes in have been
> adapted to the correct dev-branch. I safely deleted it once again. Hope
> it is gone now and confusion disappears...
>
> Best regards,
>
> Frank
>
> --
>
> Dipl.-Inform. Frank Wefers
>
> Institut für Technische Akustik (ITA)
> RWTH Aachen
> Neustraße 50
> D-52066 Aachen
>
> Phone   +49 (0) 241 80 97989
> Fax     +49 (0) 241 80 92214
> Mail    Fra...@ak...
> Web     https://www.akustik.rwth-aachen.de
>
>
> Am 02.10.2011 16:20, schrieb Jonas Stienen:
>> Hello opendaff developers,
>>
>> I myself just got confused with the second dev folder that resides in
>> the repository's root folder. It took me several minutes befor realizing
>> that I was messing around with the wrong Makefiles. I could not get the
>> same copy that should be the current revision from sourceforge via SVN ...
>> As far as I know, this dev folder has been copied to "branches/dev"
>> about 4 month ago. Still there has been some activity 2 month ago on
>> some of these files.
>>
>> Does everyone agree that we should remove this folder as soon as
>> possible and merge changes to the new developer branch?
>>
>> Cheers,
>> Jonas
>>
>> ------------------------------------------------------------------------------
>> All of the data generated in your IT infrastructure is seriously valuable.
>> Why? It contains a definitive record of application performance, security
>> threats, fraudulent activity, and more. Splunk takes this data and makes
>> sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy2
>> _______________________________________________
>> Opendaff-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opendaff-users
>>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Opendaff-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendaff-users

Re: [Opendaff-users] Request for deletion of confusing old dev folder

[Frank W. <Fra...@ak...>]

Dear DAFF users,
Dear Jonas,

toclearify things: /dev was created accidentially a year ago when 
checking in wrongly. The correct dev-branch is /branches/dev. I saw this 
mess before and had removed the false dev-branch quite a time ago and I 
am wondering that it is still/again there. All changes in have been 
adapted to the correct dev-branch. I safely deleted it once again. Hope 
it is gone now and confusion disappears...

Best regards,

Frank

--

Dipl.-Inform. Frank Wefers

Institut für Technische Akustik (ITA)
RWTH Aachen
Neustraße 50
D-52066 Aachen

Phone   +49 (0) 241 80 97989
Fax     +49 (0) 241 80 92214
Mail    Fra...@ak...
Web     https://www.akustik.rwth-aachen.de


Am 02.10.2011 16:20, schrieb Jonas Stienen:
> Hello opendaff developers,
>
> I myself just got confused with the second dev folder that resides in
> the repository's root folder. It took me several minutes befor realizing
> that I was messing around with the wrong Makefiles. I could not get the
> same copy that should be the current revision from sourceforge via SVN ...
> As far as I know, this dev folder has been copied to "branches/dev"
> about 4 month ago. Still there has been some activity 2 month ago on
> some of these files.
>
> Does everyone agree that we should remove this folder as soon as
> possible and merge changes to the new developer branch?
>
> Cheers,
> Jonas
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2dcopy2
> _______________________________________________
> Opendaff-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendaff-users
>

Re: [Opendaff-users] Build-problems with Linux.

[Frank W. <Fra...@ak...>]

Dear DAFF users,
Dear Matthias,

thank you very much for your detailled feedback. This is exactly what we 
need. I would like to encourage other users to give us feedback like 
Matthias, which will bring the project forward.

We developers were using DAFF mainly on Windows and therefore lost track 
a bit on what builds out-of-the-box and where.
I am answering with a bit of delay, as we used the meantime to fix the 
errors.

> Is there some more documentation about the build process with Linux (I
> only found COMPILING.txt)?
We are extending the document COMPILING.txt currently to give a full 
guide on building from the sources. Now you find as well notes on which 
dependencies you must install. Some parts are not yet finished. For the 
next stable version this will be 100% ready.

> In the following, I'll describe a few problems I encountered, but
> first the essence:
>
> I was able to build the library and the two helper programs after some
> fiddling around.
> However, both helper programs are crashing when I'm trying to do
> something useful with them.
Crash has been fixed. Tiny typo in a memory allocation function.
>
> Building the library worked almost out-of-the box, there was only one issue:
>
> - Missing CPU detection
>
> Makefile.Linux, line 41:
> CXX_FLAGS    := -Wall -march=i686
>
This was something written quick and fast, without thinking about other 
platforms. We changed it so -mtune=generic which determines the best 
platform optimizations automatically. Should now work for 32- and 
64-Bits. Speaking in general, we will change to some autoconf|automake 
or even CMake in the future with cares for platform properties 
automatically.
> For me (on a 64bit computer), it's -march=k8
>
> - utils/DAFFViewer/Makefile has a BOM
Fixed. Thank's for telling us. Make goals have been fixed as well.
> - build requirements: libfox, libvtk
>
> Debian packages libfox-1.6-dev, libvtk5-dev
>
Now documented inside COMPILING.txt

We tested the library and all tools on Linux with our modifications and 
everything works so far. Currently we are checking to build it on MacOS. 
Maybe next week we know more here.

To summarize the activities of the last months. We are cleaning up the 
current version, making it stable, documenting it, etc. All our changes 
are in the /branches/dev branch. We will update the /trunk in the near 
future to the next stable version. I will inform you in detail when we 
do this.

Best regards,

Frank

--

Dipl.-Inform. Frank Wefers

Institut für Technische Akustik (ITA)
RWTH Aachen
Neustraße 50
D-52066 Aachen

Phone   +49 (0) 241 80 97989
Fax     +49 (0) 241 80 92214
Mail    Fra...@ak...
Web     https://www.akustik.rwth-aachen.de

[Opendaff-users] Request for deletion of confusing old dev folder

[Jonas S. <st...@ak...>]

Hello opendaff developers,

I myself just got confused with the second dev folder that resides in
the repository's root folder. It took me several minutes befor realizing
that I was messing around with the wrong Makefiles. I could not get the
same copy that should be the current revision from sourceforge via SVN ...
As far as I know, this dev folder has been copied to "branches/dev"
about 4 month ago. Still there has been some activity 2 month ago on
some of these files.

Does everyone agree that we should remove this folder as soon as
possible and merge changes to the new developer branch?

Cheers,
Jonas

[Opendaff-users] Build-problems with Linux.

[Matthias G. <Mat...@tu...>]

Dear OpenDAFFers.

Today I did something I wanted to do since a long time ago ... build OpenDAFF.

Is there some more documentation about the build process with Linux (I
only found COMPILING.txt)?

In the following, I'll describe a few problems I encountered, but
first the essence:

I was able to build the library and the two helper programs after some
fiddling around.
However, both helper programs are crashing when I'm trying to do
something useful with them.

I didn't investigate the reason for the crashes any further, because I
guess I may have broken something while trying to compile the whole
thing.
Or maybe I just don't have the right version of some library, who knows.

Anyway, these are my experiences:

I tried the "dev" branch, because it seems to be the one with the most
recent developments.
I checked out revision 130.

Building the library worked almost out-of-the box, there was only one issue:

- Missing CPU detection

Makefile.Linux, line 41:
CXX_FLAGS    := -Wall -march=i686

For me (on a 64bit computer), it's -march=k8

After that, it compiled without further problems.

Then I tried to compile DAFFViewer, this was much more cumbersome:

- utils/DAFFViewer/Makefile has a BOM

Therefore, make doesn't work!

Solution: remove the BOM (in Vim, use :set nobomb)

- utils/DAFFViewer/Makefile has wrong default goal

.DEFAULT_GOAL := DAFFTool

this should be:

.DEFAULT_GOAL := DAFFViewer

- build requirements: libfox, libvtk

Debian packages libfox-1.6-dev, libvtk5-dev

Is this documented somewhere?

Due to some conflicts, I had to install the rather old version libvtk
5.0.4, is this too old?

- utils/DAFFViewer/Makefile: include FXVTK2?

Adding -I../../3rdparty/FXVTK2/include to the compile command works.

- utils/DAFFViewer/Makefile: include vtk?

Adding -I/usr/include/vtk-5.0 works for me (for now).

For linking, I also had to add -lvtkRendering

- 3rdparty/FXVTK2/include/FXVTK2FileImport.h:32

#include <string>

When using string.h, the std:: namespace isn't used.

same here:
3rdparty/FXVTK2/include/FXVTK2Label.h:53

- 3rdparty/FXVTK2/include/FXVTK2Label.h:101

"class" missing:

friend class Frame;

- Where/how is FXVTK2 built?

I just added those to VIEWER_SRC:

FXVTK2SGNode.cpp
FXVTK2SphereCoordinateAssistant.cpp
FXVTK2Frame.cpp
FXVTK2Arrow.cpp
FXVTK2Sphere.cpp
FXVTK2Line.cpp
FXVTK2GlobalLock.cpp
FXVTK2Directivity.cpp

- DAFFViewer: many warnings during compilation

I just disabled -Wall, but maybe the warnings should be fixed?

- 3rdparty/FXVTK2/src/FXVTK2Directivity.cpp:41

SGNode::~SGNode();

That's the error:

 error: no matching function for call to ‘FXVTK2::Directivity::~Directivity()’
 note: candidates are: virtual FXVTK2::SGNode::~SGNode()
(3rdparty/FXVTK2/include/FXVTK2SGNode.h, line 83)

I don't know what's wrong, I just deleted it to be able to continue building.
I never explicitly called a destructor, so I don't know how this is
supposed to work.

same here:
/3rdparty/FXVTK2/src/FXVTK2SphereCoordinateAssistant.cpp:171

I have the feeling that deleting those lines isn't really a solution ...

- 3rdparty/FXVTK2/src/FXVTK2Arrow.cpp:110

error: no matching function for call to
‘vtkProperty::GetColor(double&, double&, double&)

I guess I'm using the wrong vtk version, because in my version, the signature is

void GetColor(double rgb[3]);

same here:
3rdparty/FXVTK2/src/FXVTK2Sphere.cpp:90
3rdparty/FXVTK2/src/FXVTK2Line.cpp:86

I just disabled those lines.

Now finally, it compiled!

Launching daffviewer works, a window appears, showing a nice 3D
coordinate system, but when I try to open an OpenDAFF file, the
program crashes with this:

*** glibc detected *** ./daffviewer: malloc(): memory corruption:
0x000000000251bbe0 ***
[Backtrace snipped]

Finally, I tried to build DAFFTool:

- utils/DAFFTool/Makefile:32

I guess -ldaff should be -lDAFF, otherwise it isn't found, because the
file is called libDAFF.a.
We Linux guys take case-sensitivity quite seriously.

Sadly, dafftool also crashes (for example when I try to use the "info" command).

Does anyone have an idea how I could avoid all those manipulations I
did in order to compile the stuff?

cheers,
Matthias

Re: [Opendaff-users] Storage of a 2D impulse response

[<Hag...@te...>]

Hello Jonas.
 
I have used a beta resolution of 90° and stored two dirac pulses at the poles and everything works fine.
 
Another nice thing: I was able to do all the stuff (compiling the mex file, creating and reading the DAFF files) only by using Octave. I had to change a few lines of code, but it worked.
 
/Hagen
 

 

________________________________

	From: Jonas Stienen [mailto:st...@ak...] 
	Sent: Freitag, 19. November 2010 12:32
	To: Wierstorf, Hagen
	Cc: ope...@li...
	Subject: AW: [Opendaff-users] Storage of a 2D impulse response
	
	
	Hello Hagen,
	
	in principle this should work since the design goal was to create an interface that can deal with arbitrary points on a sphere. In the current revision only regular grids are implemented though (alpha is azimuth an beta ist elevation in your case). To be honest we have only worked with full sphere covered datasets so far and did not test a simple circle. 
	As far as I know with the daff_write method you are not able to write the daff file you are looking for, i am afraid ... But maybe validate for a call with betares is 180, alphares whatever matches your data resolution in azimuthal range and and set the yaw-pitch-roll orientation to zero zero zero. Does it run into the if-case where it checks wether it is a north- or southpole? Because in this case there is only one dataset required.
	For a quick workaround use betares is 90 that will create your circle and additonally a dataset at north- an southpole (use a dirac or whateveryou like). When you use Daff now (getRecordIndex) set elevation always to zero and you will receive the quested filter.
	
	And by the way I will come back to this because I know that some other guys are going to request exactly what you are seeking, too. So I will have to cope with that problem in some time anyway ... look for DAFF updates.
	
	Oh and I guess you use the dev branch, right? I think you should, because v101 has some new features and less bugs, though it is not committed to the trunk.
	
	Kind Regards to you and the audio group,
	Jonas
	
	
	
	-- send via mobile phone
	
	Jonas Stienen
	
	Acoustic Virtual Reality Laboratory
	Institute of Technical Acoustics
	RWTH Aachen University
	Neustraße 50
	D-52066 Aachen
	
	Tel.: +49 (0) 241 / 80 - 97989 <tel:+49 (0) 241 / 80 - 97989> 
	
	Mail: st...@ak...
	Web: http://www.akustik.rwth-aachen.de

	
________________________________

	Hag...@te... <Hag...@te...> schrieb am 19.11.2010 11:37: 
	
	Hello. 
	
	First we are very happy that someone has started to work on a file format for directional audio data as we are working a lot with HRIRs. 
	
	I have checked out the svn data and checked the matlab implementation. I tried to store one of our HRIRs data set with the daff_write.m function, but the problem is that we have only values in the azimuth plane and no elevation at all. Is it possible to store only these values (what value for 'betares' is needed in this case?)? 
	In general it would be nice if some more documentation could be added to the svn or the web page ;) 
	
	Best regards 
	Hagen and the rest of the audio group at T-Labs 
	
	--- 
	http://audio.qu.tu-berlin.de/ 
	------------------------------------------------------------------------------ 
	Beautiful is writing same markup. Internet Explorer 9 supports 
	standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. 
	Spend less time writing and rewriting code and more time creating great 
	experiences on the web. Be a part of the beta today 
	http://p.sf.net/sfu/msIE9-sfdev2dev 
	_______________________________________________ 
	Opendaff-users mailing list 
	Ope...@li... 
	https://lists.sourceforge.net/lists/listinfo/opendaff-users 
	

[Opendaff-users] Storage of a 2D impulse response

[<Hag...@te...>]

Hello.

First we are very happy that someone has started to work on a file format for directional audio data as we are working a lot with HRIRs.

I have checked out the svn data and checked the matlab implementation. I tried to store one of our HRIRs data set with the daff_write.m function, but the problem is that we have only values in the azimuth plane and no elevation at all. Is it possible to store only these values (what value for 'betares' is needed in this case?)?
In general it would be nice if some more documentation could be added to the svn or the web page ;)

Best regards
Hagen and the rest of the audio group at T-Labs

---
http://audio.qu.tu-berlin.de/