[Spatdif] Fwd: SpatDIF question

[Trond Lossius]

Hi,

I am forwarding this mail from Francesco Vitale in order to be able to continue the discussion on the list.

Best,

Trond

Begin forwarded message:

From: Francesco Vitale <[hidden email]>

Date: April 22, 2011 11:03:25 AM GMT+02:00

To: [hidden email]

Subject: SpatDIF question

Reply-To: [hidden email]

Distinguished Dr. Lossius, 

given your recognized authority in the SpatDIF field, I have a question concerning the writing of a 3D trajectory in a SDIF file. First of all, I must premise that I am not an expert in this kind of issues: as a simple user of the SpatDIF technology, I'm interested in saving three-dimensional curves in a SDIF format, and the trajectories with which I'm working are stored in a text file as a list of x, y, and z coordinates, like in the following example: 

-37.0 2.0 19.0

-14.0 -10.0 9.0

-11.0 -7.0 0.0

-9.164619 1.25919 9.63573

...

Now, I noticed that, in accordance to the SpatDIF storing conventions, the trajectory is written in SDIF taking only one x, y, z point per frame. Here you have an example portion of the SDIF content obtained from the x, y, z data that exemplifies this:

XSRC 1 1 0

  XCAR 0x0004 1 3

-37 2 19

XSRC 1 1 0.452506

  XCAR 0x0004 1 3

-14 -10 9

XSRC 1 1 0.614445

  XCAR 0x0004 1 3

-11 -7 0

XSRC 1 1 0.823146

  XCAR 0x0004 1 3

-9.16462 1.25919 9.63573

...

In this way, the 3D curve is subject to an alteration, because its shape is distorted along the time axis.

Thus my question is: starting with a trajectory, is it possible to store it in a SDIF without distorting it, in order to leave its form unchanged? Is there, in SpatDIF, the possibility to write the trajectory leaving it unaltered, i. e. (as far as I can tell) assigning more x, y, z points to the same frame? 

Attached to this mail you have some examples of this distortions (the alteration I'm talking about can be noticed only displaying visually the stored curves with programs like SDIF-Edit, not ispecting the sdif data as text). In the "Nils' curve" pdf you find a simple 2D circular trajectory, created by Nils Peters with a SpatDIF recording application that he's currently developing at IRCAM. You can see that the original curve presented on the top half of the pdf gets always distorted, leaving as result the curve presented on the bottom half of the pdf.

I noticed that, because of this distortion, the curves used as a starting material are transmogrified through what I'd call a "time perspectival anamorphosis": in fact, the resulting shapes seem always to be the distorted projection (along the time axis) of the initial 3D forms, which can be rectified only from the Z/Y viewpoint (see the screenshot taken from OpenMusic contained in the "Curve (Nils Peters)" pdf).

I've attached also a more complex example (see the "3D trajectory and its SDIF storing" pdf) in which the starting shape (on the top half) is altered through the time anamorphosis (on the bottom half).

Now, I could have found something that, in theory, could work as a solution to the problem of the distortion of the curves in the SpatDIF storing: to preserve their original form, I thought that maybe the frames of the SpatDIF should be resampled with an higher frequency. But with such resampling the time information in the SpatDIF would be lost, and I understand that the SpatDIF was conceived to store also this type of information. Nevertheless, if you store (for example) a circular trajectory in a SpatDIF, this trajectory would be never visualized or displayed as circular, because the coordinate information is combined with the time information. The circular trajectory would appear as circular only outside time. Maybe someone that develops the SpatDIF format (like you) should consider the option of storing only the coordinate information. It would be great if you could take this into account. Please let me know what do you think about it.

Thanks in advance for your kind attention and concern.

                                                                      Best regards, 

                                                                   Francesco Vitale

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Jan Schacher]

Hello Francesco,

Thanks for asking the same question again. Let me reiterate my previous answer.

The problems you are observing aren't inherent to either the SDIF nor SpatDIF format, they must be an artifact of the specific tool-chain you are using.

Since nobody on this list actually knows or has your exact setup, it will be impossible to analyze your problem and help you find a solution for it.

I would advise you to address the authors of each piece of software you are using in order to determine where the information gets lost.

To answer some of the simpler questions you ask:
In SpatDIF we have two ways of looking at data, either frame-based or stream-based. In the frame-based representations all events that fall on a specific time-point will be grouped. In the stream-based version all events belonging to a specific stream (track) will be grouped.
IMHO SDIF works only in the latter paradigm and maybe one your specific software implementations mixes up the two in an unfortunate manner?

Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to the software implementer to store as many time-points as necessary to represent a trajectory faithfully.

best regards

/*j


////////////////

Zurich University of the Arts
Music Department
Institute for Computer Music and Sound Technology

Jan Schacher
Associate Researcher

Baslerstrasse 30
CH-8048 Zürich
Telephone [phone]

jan [dot] schacher [at] zhdk [dot] ch

http://www.zhdk.ch
http://www.icst.net

> From: Francesco Vitale <[hidden email]>
> Date: April 22, 2011 11:03:25 AM GMT+02:00
> To: [hidden email]
> Subject: SpatDIF question
> Reply-To: [hidden email]
>
> Distinguished Dr. Lossius,
> given your recognized authority in the SpatDIF field, I have a question concerning the writing of a 3D trajectory in a SDIF file. First of all, I must premise that I am not an expert in this kind of issues: as a simple user of the SpatDIF technology, I'm interested in saving three-dimensional curves in a SDIF format, and the trajectories with which I'm working are stored in a text file as a list of x, y, and z coordinates, like in the following example:
>
> -37.0 2.0 19.0
> -14.0 -10.0 9.0
> -11.0 -7.0 0.0
> -9.164619 1.25919 9.63573
> ...
>
> Now, I noticed that, in accordance to the SpatDIF storing conventions, the trajectory is written in SDIF taking only one x, y, z point per frame. Here you have an example portion of the SDIF content obtained from the x, y, z data that exemplifies this:
>
> XSRC 1 1 0
>  XCAR 0x0004 1 3
> -37 2 19
>
> XSRC 1 1 0.452506
>  XCAR 0x0004 1 3
> -14 -10 9
>
> XSRC 1 1 0.614445
>  XCAR 0x0004 1 3
> -11 -7 0
>
> XSRC 1 1 0.823146
>  XCAR 0x0004 1 3
> -9.16462 1.25919 9.63573
> ...
>
> In this way, the 3D curve is subject to an alteration, because its shape is distorted along the time axis.
> Thus my question is: starting with a trajectory, is it possible to store it in a SDIF without distorting it, in order to leave its form unchanged? Is there, in SpatDIF, the possibility to write the trajectory leaving it unaltered, i. e. (as far as I can tell) assigning more x, y, z points to the same frame?
> Attached to this mail you have some examples of this distortions (the alteration I'm talking about can be noticed only displaying visually the stored curves with programs like SDIF-Edit, not ispecting the sdif data as text). In the "Nils' curve" pdf you find a simple 2D circular trajectory, created by Nils Peters with a SpatDIF recording application that he's currently developing at IRCAM. You can see that the original curve presented on the top half of the pdf gets always distorted, leaving as result the curve presented on the bottom half of the pdf.
> I noticed that, because of this distortion, the curves used as a starting material are transmogrified through what I'd call a "time perspectival anamorphosis": in fact, the resulting shapes seem always to be the distorted projection (along the time axis) of the initial 3D forms, which can be rectified only from the Z/Y viewpoint (see the screenshot taken from OpenMusic contained in the "Curve (Nils Peters)" pdf).
> I've attached also a more complex example (see the "3D trajectory and its SDIF storing" pdf) in which the starting shape (on the top half) is altered through the time anamorphosis (on the bottom half).
> Now, I could have found something that, in theory, could work as a solution to the problem of the distortion of the curves in the SpatDIF storing: to preserve their original form, I thought that maybe the frames of the SpatDIF should be resampled with an higher frequency. But with such resampling the time information in the SpatDIF would be lost, and I understand that the SpatDIF was conceived to store also this type of information. Nevertheless, if you store (for example) a circular trajectory in a SpatDIF, this trajectory would be never visualized or displayed as circular, because the coordinate information is combined with the time information. The circular trajectory would appear as circular only outside time. Maybe someone that develops the SpatDIF format (like you) should consider the option of storing only the coordinate information. It would be great if you could take this into account. Please let me know what do you think about it.
> Thanks in advance for your kind attention and concern.
>                                                                      Best regards,
>                                                                   Francesco Vitale

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Trond Lossius]

Dear Francesco,

Following up on the reply from Jan I am still trying to understand exactly what you try to achieve. Specifically:

- Do you try to describe the trajectory of a point over time (so that the position [x,y,z] of the point is a function of time)
- Or do you try to describe a shape or three-dimensional curve at one point in time
- Or something else?

For further discussions it would be useful if you could provide the details of what you want to achieve, including:

- A sample file in text format providing "good data", that is the data you want to start out from and that has the form you'd like them to have
- A description of the steps you take to produce the curves
- Possibly intermediate data files
- End data and curves with descriptions of exactly what the errors are and where to find them in the data and curves.

If there indeed is a problem with the SpatDIF spec this will help us understand what the problem is. And likewise if there is a issue with the approach, processing or bugs in one of the programs used along the way, it might be easier to track down where it happens and help identify the issue so that it could be sorted out.

Thanks,
Trond


PS: For anyone trying to read the pdf attached to the first mail on the list, please open them in Acrobat Reader, not any other pdf readers, in order to see and interact with the 3D visuals.


On Jun 15, 2011, at 10:31 AM, Jan Schacher wrote:

> Hello Francesco,
>
> Thanks for asking the same question again. Let me reiterate my previous answer.
>
> The problems you are observing aren't inherent to either the SDIF nor SpatDIF format, they must be an artifact of the specific tool-chain you are using.
>
> Since nobody on this list actually knows or has your exact setup, it will be impossible to analyze your problem and help you find a solution for it.
>
> I would advise you to address the authors of each piece of software you are using in order to determine where the information gets lost.
>
> To answer some of the simpler questions you ask:
> In SpatDIF we have two ways of looking at data, either frame-based or stream-based. In the frame-based representations all events that fall on a specific time-point will be grouped. In the stream-based version all events belonging to a specific stream (track) will be grouped.
> IMHO SDIF works only in the latter paradigm and maybe one your specific software implementations mixes up the two in an unfortunate manner?
>
> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to the software implementer to store as many time-points as necessary to represent a trajectory faithfully.
>
> best regards
>
> /*j
>
>
> ////////////////
>
> Zurich University of the Arts
> Music Department
> Institute for Computer Music and Sound Technology
>
> Jan Schacher
> Associate Researcher
>
> Baslerstrasse 30
> CH-8048 Zürich
> Telephone [phone]
>
> jan [dot] schacher [at] zhdk [dot] ch
>
> http://www.zhdk.ch
> http://www.icst.net
>
>
>> From: Francesco Vitale <[hidden email]>
>> Date: April 22, 2011 11:03:25 AM GMT+02:00
>> To: [hidden email]
>> Subject: SpatDIF question
>> Reply-To: [hidden email]
>>
>> Distinguished Dr. Lossius,
>> given your recognized authority in the SpatDIF field, I have a question concerning the writing of a 3D trajectory in a SDIF file. First of all, I must premise that I am not an expert in this kind of issues: as a simple user of the SpatDIF technology, I'm interested in saving three-dimensional curves in a SDIF format, and the trajectories with which I'm working are stored in a text file as a list of x, y, and z coordinates, like in the following example:
>>
>> -37.0 2.0 19.0
>> -14.0 -10.0 9.0
>> -11.0 -7.0 0.0
>> -9.164619 1.25919 9.63573
>> ...
>>
>> Now, I noticed that, in accordance to the SpatDIF storing conventions, the trajectory is written in SDIF taking only one x, y, z point per frame. Here you have an example portion of the SDIF content obtained from the x, y, z data that exemplifies this:
>>
>> XSRC 1 1 0
>> XCAR 0x0004 1 3
>> -37 2 19
>>
>> XSRC 1 1 0.452506
>> XCAR 0x0004 1 3
>> -14 -10 9
>>
>> XSRC 1 1 0.614445
>> XCAR 0x0004 1 3
>> -11 -7 0
>>
>> XSRC 1 1 0.823146
>> XCAR 0x0004 1 3
>> -9.16462 1.25919 9.63573
>> ...
>>
>> In this way, the 3D curve is subject to an alteration, because its shape is distorted along the time axis.
>> Thus my question is: starting with a trajectory, is it possible to store it in a SDIF without distorting it, in order to leave its form unchanged? Is there, in SpatDIF, the possibility to write the trajectory leaving it unaltered, i. e. (as far as I can tell) assigning more x, y, z points to the same frame?
>> Attached to this mail you have some examples of this distortions (the alteration I'm talking about can be noticed only displaying visually the stored curves with programs like SDIF-Edit, not ispecting the sdif data as text). In the "Nils' curve" pdf you find a simple 2D circular trajectory, created by Nils Peters with a SpatDIF recording application that he's currently developing at IRCAM. You can see that the original curve presented on the top half of the pdf gets always distorted, leaving as result the curve presented on the bottom half of the pdf.
>> I noticed that, because of this distortion, the curves used as a starting material are transmogrified through what I'd call a "time perspectival anamorphosis": in fact, the resulting shapes seem always to be the distorted projection (along the time axis) of the initial 3D forms, which can be rectified only from the Z/Y viewpoint (see the screenshot taken from OpenMusic contained in the "Curve (Nils Peters)" pdf).
>> I've attached also a more complex example (see the "3D trajectory and its SDIF storing" pdf) in which the starting shape (on the top half) is altered through the time anamorphosis (on the bottom half).
>> Now, I could have found something that, in theory, could work as a solution to the problem of the distortion of the curves in the SpatDIF storing: to preserve their original form, I thought that maybe the frames of the SpatDIF should be resampled with an higher frequency. But with such resampling the time information in the SpatDIF would be lost, and I understand that the SpatDIF was conceived to store also this type of information. Nevertheless, if you store (for example) a circular trajectory in a SpatDIF, this trajectory would be never visualized or displayed as circular, because the coordinate information is combined with the time information. The circular trajectory would appear as circular only outside time. Maybe someone that develops the SpatDIF format (like you) should consider the option of storing only the coordinate information. It would be great if you could take this into account. Please let me know what do you think about it.
>> Thanks in advance for your kind attention and concern.
>>                                                                     Best regards,
>>                                                                  Francesco Vitale
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Diemo Schwarz]

On 15.06.11 10:31, Jan Schacher wrote:
> To answer some of the simpler questions you ask: In SpatDIF we have two ways
> of looking at data, either frame-based or stream-based. In the frame-based
> representations all events that fall on a specific time-point will be
> grouped. In the stream-based version all events belonging to a specific
> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
> and maybe one your specific software implementations mixes up the two in an
> unfortunate manner?

Just to rebound on the last point: the frame-based representation would be
easily represented in SDIF by using the rows of a matrix for different xyz
points, but you have to make sure all points are always present.  If you want to
loosen that requirement, you'd need to introduce and handle an index column
(ixyz) --- that's probably better handled by streams.
(I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but
don't know if it is in the spec).

Cheers...
                                                                ...Diemo


> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
> the software implementer to store as many time-points as necessary to
> represent a trajectory faithfully.

--
Diemo Schwarz, PhD -- http://diemo.concatenative.net
Real-Time Music Interaction Team -- http://imtr.ircam.fr
IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
Phone [phone] -- Fax [phone]
_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Schumacher Marlon]

Hello Francesco and all,

Back from a trip I just quickly read over this thread, but to shed some light re:storage of spatial descriptors in SDIF may I point you to the proposal given at the SpatDIF/GDIF meeting 2010 ( http://imtr.ircam.fr/imtr/images/Bresson-schumacher.pdf ) and the 2010 JIM-paper ( http://www.idmil.org/_media/publications/2010/bresson-jim2010.pdf ) and this year's ICMC-paper (yet unpublished), in which these ideas are discussed. E.g. rows of matrices can be used to represent a certain descriptor (such as position) of multiple sound sources at the same point in time, and streams can be used for heterogenous descriptions. Btw, this is also already implemented and available in the OpenMusic spatialization-tools OMPrisma ( http://www.idmil.org/software/omprisma ) and OMSpat ( http://repmus.ircam.fr/bresson/projects/spatialisation ).

Cheers,
Marlon

On 2011-06-15, at 04:57 , Diemo Schwarz wrote:

>
> On 15.06.11 10:31, Jan Schacher wrote:
>> To answer some of the simpler questions you ask: In SpatDIF we have two ways
>> of looking at data, either frame-based or stream-based. In the frame-based
>> representations all events that fall on a specific time-point will be
>> grouped. In the stream-based version all events belonging to a specific
>> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
>> and maybe one your specific software implementations mixes up the two in an
>> unfortunate manner?
>
> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>
> Cheers...
> ...Diemo
>
>
>> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
>> the software implementer to store as many time-points as necessary to
>> represent a trajectory faithfully.
>
> --
> Diemo Schwarz, PhD -- http://diemo.concatenative.net
> Real-Time Music Interaction Team -- http://imtr.ircam.fr
> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
> Phone [phone] -- Fax [phone]
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif
>

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Jean Bresson]

Hi all,

We've posted a few months ago a proposal for SIDF spatial descriptions of the Type Grafitti Wall of the SDIF Wiki
[ http://sourceforge.net/apps/mediawiki/sdif/index.php?title=SDIF_Type_Grafitti_Wall#SDIF_spatial_scenes_description ]

These are the convention adopted in OpenMusic and the Spat for storing and interchange trajectories and other spatial descriptions.

Jean


Le 15 juin 2011 à 10:57, Diemo Schwarz a écrit :

>
> On 15.06.11 10:31, Jan Schacher wrote:
>> To answer some of the simpler questions you ask: In SpatDIF we have two ways
>> of looking at data, either frame-based or stream-based. In the frame-based
>> representations all events that fall on a specific time-point will be
>> grouped. In the stream-based version all events belonging to a specific
>> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
>> and maybe one your specific software implementations mixes up the two in an
>> unfortunate manner?
>
> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>
> Cheers...
> ...Diemo
>
>
>> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
>> the software implementer to store as many time-points as necessary to
>> represent a trajectory faithfully.
>
> --
> Diemo Schwarz, PhD -- http://diemo.concatenative.net
> Real-Time Music Interaction Team -- http://imtr.ircam.fr
> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
> Phone [phone] -- Fax [phone]
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif
>

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Francesco Vitale]

Hi all, 

thanks for your answers. Trond asked me to provide:
- A sample file in text format providing "good data", that is the data you want to start out from and that has the form you'd like them to have.
As for this request, I can provide a text file containing a list of x, y, and z coordinates (i. e. a point cloud data file) – see the "Marlon's curve" attachment.

- A description of the steps you take to produce the curves.
The curves are produced within Ircam's OpenMusic, through the use of various OM functions (see the OM patch attached, which describes the creation of a curve starting from scratch).

- End data and curves with descriptions of exactly what the errors are and where to find them in the data and curves.

They cannot be called properly "errors", because there's nothing intrinsically wrong in the chosen storing method; the only "wrong" thing is that, with this method, one cannot visualize or sonify the curve with its original shape because each point of the trajectory is placed in a different frame, and this destructs the form of the curve. This "incorrect" storing of the curve is shown in the aforementioned OM patch (as well as in the "3D trajectory and its SDIF storing" pdf). In order to inspect visually the SpatDIF, I use the SDIF-Edit program, the only one that displays the content of a SpatDIF in 3D. Again, there are no bugs in SDIF-Edit that can be considered as the cause of the distortion (SDIF-Edit simply visualizes the curve which has been already distorted when it's written as a SpatDIF). 

In conclusion, what I'd need to achieve is a SpatDIF storing that preserves the shape of the curve so that program like SDIF-Edit can display it with its original form. Thanks again for your kind attention. 

                  Best, 

          Francesco Vitale

2011/6/15 Diemo Schwarz <[hidden email]>

On 15.06.11 10:31, Jan Schacher wrote:

To answer some of the simpler questions you ask: In SpatDIF we have two ways
of looking at data, either frame-based or stream-based. In the frame-based
representations all events that fall on a specific time-point will be
grouped. In the stream-based version all events belonging to a specific
stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
and maybe one your specific software implementations mixes up the two in an
unfortunate manner?

Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
(I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).

Cheers...
                                                               ...Diemo

Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
the software implementer to store as many time-points as necessary to
represent a trajectory faithfully.

--
Diemo Schwarz, PhD -- http://diemo.concatenative.net
Real-Time Music Interaction Team -- http://imtr.ircam.fr
IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
Phone [phone] -- Fax [phone]

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Schumacher Marlon]

Hi Francesco,

Is it possible that what you'd like to describe is a geometric shape (probably the 'point cloud' outside a temporal context) rather than a trajectory (position of a single point unfolding over time)?

In this case we need to represent n points in space at the same point in time, i.e. in the same frame. In principle you can achieve this e.g. by converting the original trajectory into a number of discrete positions and then write them into a single matrix (e.g. if you'd like to change the geometric shape synchronously over time), or into n matrices (one for each source), e.g. if the positions of the individual points/sources should evolve asynchronously.

Marlon


On 2011-06-15, at 13:45 , Francesco Vitale wrote:

> Hi all,
> thanks for your answers. Trond asked me to provide:
> - A sample file in text format providing "good data", that is the data you want to start out from and that has the form you'd like them to have.
> As for this request, I can provide a text file containing a list of x, y, and z coordinates (i. e. a point cloud data file) – see the "Marlon's curve" attachment.
> - A description of the steps you take to produce the curves.
> The curves are produced within Ircam's OpenMusic, through the use of various OM functions (see the OM patch attached, which describes the creation of a curve starting from scratch).
> - End data and curves with descriptions of exactly what the errors are and where to find them in the data and curves.
> They cannot be called properly "errors", because there's nothing intrinsically wrong in the chosen storing method; the only "wrong" thing is that, with this method, one cannot visualize or sonify the curve with its original shape because each point of the trajectory is placed in a different frame, and this destructs the form of the curve. This "incorrect" storing of the curve is shown in the aforementioned OM patch (as well as in the "3D trajectory and its SDIF storing" pdf). In order to inspect visually the SpatDIF, I use the SDIF-Edit program, the only one that displays the content of a SpatDIF in 3D. Again, there are no bugs in SDIF-Edit that can be considered as the cause of the distortion (SDIF-Edit simply visualizes the curve which has been already distorted when it's written as a SpatDIF).
> In conclusion, what I'd need to achieve is a SpatDIF storing that preserves the shape of the curve so that program like SDIF-Edit can display it with its original form. Thanks again for your kind attention.
>                   Best,
>           Francesco Vitale
>
> 2011/6/15 Diemo Schwarz <[hidden email]>
>
> On 15.06.11 10:31, Jan Schacher wrote:
> To answer some of the simpler questions you ask: In SpatDIF we have two ways
> of looking at data, either frame-based or stream-based. In the frame-based
> representations all events that fall on a specific time-point will be
> grouped. In the stream-based version all events belonging to a specific
> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
> and maybe one your specific software implementations mixes up the two in an
> unfortunate manner?
>
> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>
> Cheers...
>                                                                ...Diemo
>
>
>
> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
> the software implementer to store as many time-points as necessary to
> represent a trajectory faithfully.
>
> --
> Diemo Schwarz, PhD -- http://diemo.concatenative.net
> Real-Time Music Interaction Team -- http://imtr.ircam.fr
> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
> Phone [phone] -- Fax [phone]
>
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif
>
> <Marlon's curve.txt><patch 1.omp>_______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Schumacher Marlon-2]

Hi,

> ... and then write them into a single matrix (e.g. if you'd like to change the geometric shape synchronously over time), or into n matrices (one for each source), e.g. if the positions of the individual points/sources should evolve asynchronously.


sorry, what I was intending to say was:

...and then write/group them into the same matrix (one for all sources) in a single stream, or into individual matrices in n individual streams (one for each source).

Best,
Marlon
_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Francesco Vitale]

Dear Marlon, 

I think you're right. Describing a geometric shape in a SparDIF rather than «the position of a single point unfolding over time» is exactly my purpose. But what do you mean saying that I should convert «the original trajectory into a number of discrete positions»? I only have a vague idea about this operation, but I know that the geometric shape, in theory, should be sliced by n vertical section planes which, in their turn, intersecting the cloud, identify the family of points that fall under the same given time t.

However, this slicing algorithm should be defined in the same way it has been defined the algorithm that assigns every point in the cloud at a different time t...

              Francesco

2011/6/15 Schumacher Marlon <[hidden email]>

Hi Francesco,

Is it possible that what you'd like to describe is a geometric shape (probably the 'point cloud' outside a temporal context) rather than a trajectory (position of a single point unfolding over time)?

In this case we need to represent n points in space at the same point in time, i.e. in the same frame. In principle you can achieve this e.g. by converting the original trajectory into a number of discrete positions and then write them into a single matrix (e.g. if you'd like to change the geometric shape synchronously over time), or into n matrices (one for each source), e.g. if the positions of the individual points/sources should evolve asynchronously.

Marlon

On 2011-06-15, at 13:45 , Francesco Vitale wrote:

> Hi all,
> thanks for your answers. Trond asked me to provide:
> - A sample file in text format providing "good data", that is the data you want to start out from and that has the form you'd like them to have.
> As for this request, I can provide a text file containing a list of x, y, and z coordinates (i. e. a point cloud data file) – see the "Marlon's curve" attachment.
> - A description of the steps you take to produce the curves.
> The curves are produced within Ircam's OpenMusic, through the use of various OM functions (see the OM patch attached, which describes the creation of a curve starting from scratch).
> - End data and curves with descriptions of exactly what the errors are and where to find them in the data and curves.
> They cannot be called properly "errors", because there's nothing intrinsically wrong in the chosen storing method; the only "wrong" thing is that, with this method, one cannot visualize or sonify the curve with its original shape because each point of the trajectory is placed in a different frame, and this destructs the form of the curve. This "incorrect" storing of the curve is shown in the aforementioned OM patch (as well as in the "3D trajectory and its SDIF storing" pdf). In order to inspect visually the SpatDIF, I use the SDIF-Edit program, the only one that displays the content of a SpatDIF in 3D. Again, there are no bugs in SDIF-Edit that can be considered as the cause of the distortion (SDIF-Edit simply visualizes the curve which has been already distorted when it's written as a SpatDIF).
> In conclusion, what I'd need to achieve is a SpatDIF storing that preserves the shape of the curve so that program like SDIF-Edit can display it with its original form. Thanks again for your kind attention.
>                   Best,
>           Francesco Vitale
>
> 2011/6/15 Diemo Schwarz <[hidden email]>
>
> On 15.06.11 10:31, Jan Schacher wrote:
> To answer some of the simpler questions you ask: In SpatDIF we have two ways
> of looking at data, either frame-based or stream-based. In the frame-based
> representations all events that fall on a specific time-point will be
> grouped. In the stream-based version all events belonging to a specific
> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
> and maybe one your specific software implementations mixes up the two in an
> unfortunate manner?
>
> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>
> Cheers...
>                                                                ...Diemo
>
>
>
> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
> the software implementer to store as many time-points as necessary to
> represent a trajectory faithfully.
>
> --
> Diemo Schwarz, PhD -- http://diemo.concatenative.net
> Real-Time Music Interaction Team -- http://imtr.ircam.fr
> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
> Phone [phone] -- Fax [phone]
>
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif
>

> <Marlon's curve.txt><patch 1.omp>_______________________________________________

> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Trond Lossius]

Dear Francesco,

> I think you're right. Describing a geometric shape in a SparDIF rather than «the position of a single point unfolding over time» is exactly my purpose.

If so, I can understand that stuff might get mangled. If all points in reality exists simultaneaous, at the same point in time, and the line from one point to the next need to be drawn in a specific sequence in order to render the curve correctly, I can understand that the curve might get mangled if the sequence of points get reshuffled.

At the time being I don't think we have any support (or specification for how to describe) geometric shapes. I would assume that for you to draw a geometric shape correctly, you have to draw a line from one point to the next in a specific sequence. One hackish workaround would be to introduce a delta step so that you use the time dimension as an index for organizing the sequence of the points.

Of course, if the shape itself change over time, this won't work.

May I ask what you are using this shape for? I think it would be useful to know more about the use case that you are dealing with, in order to understand what challenges and need it might call for.

Thanks,
Trond
_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Trond Lossius]

Thanks for this link, Jean!

Out of curiosity, have you decided on any coordinate system conventions for Cartesian and spherical coordinates?

Apart from that, I am also wondering about the SDIF abbreviations for the following:

1MTD XCAR {x, y, z}
1MTD XSPH {azimuth, zenith, distance}
1MTD XCYL {azimuth, distance, elevation}

If SPH in XSPH is an abbreviation for spherical and CYL in XCYL is short for cylindric, wouldn't the following be more appropriate?

1MTD XCAR {x, y, z}
1MTD XSPH {azimuth, distance, elevation}
1MTD XCYL {azimuth, zenith, distance}

In the latter: Is "distance" describing distance in the horizontal plane, or three-dimensional distance?

I'm also wondering if there is a reason why distance is set to be the 2nd element in one and the 3rd element in the other. Would it perhaps be better to organize the spherical coordinates as {azimuth, elevation, distance}, is is done in the ICST externals for Max?


Yours,
Trond


On Jun 15, 2011, at 5:28 PM, Jean Bresson wrote:

> Hi all,
>
> We've posted a few months ago a proposal for SIDF spatial descriptions of the Type Grafitti Wall of the SDIF Wiki
> [ http://sourceforge.net/apps/mediawiki/sdif/index.php?title=SDIF_Type_Grafitti_Wall#SDIF_spatial_scenes_description ]
>
> These are the convention adopted in OpenMusic and the Spat for storing and interchange trajectories and other spatial descriptions.
>
> Jean
>
>
> Le 15 juin 2011 à 10:57, Diemo Schwarz a écrit :
>
>>
>> On 15.06.11 10:31, Jan Schacher wrote:
>>> To answer some of the simpler questions you ask: In SpatDIF we have two ways
>>> of looking at data, either frame-based or stream-based. In the frame-based
>>> representations all events that fall on a specific time-point will be
>>> grouped. In the stream-based version all events belonging to a specific
>>> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
>>> and maybe one your specific software implementations mixes up the two in an
>>> unfortunate manner?
>>
>> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
>> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>>
>> Cheers...
>> ...Diemo
>>
>>
>>> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
>>> the software implementer to store as many time-points as necessary to
>>> represent a trajectory faithfully.
>>
>> --
>> Diemo Schwarz, PhD -- http://diemo.concatenative.net
>> Real-Time Music Interaction Team -- http://imtr.ircam.fr
>> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
>> Phone [phone] -- Fax [phone]
>> _______________________________________________
>> Spatdif mailing list
>> [hidden email]
>> https://mail.bek.no/mailman/listinfo/spatdif
>>
>
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Francesco Vitale]

Dear Trond, 

you asked me: «what you are using this shape for?». My aim is to store the geometric data in a SpatDIF in order to work with them for sonification and spatialization purposes. I tried to attach some practical examples contained in an OM patch, but I got this warning message: 

Delivery to the following recipient failed permanently:

    [hidden email]

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 552 552 5.3.4 Error: message file too big (state 18).

Tell me what should I do if you'd need to receive this material. 

                      Best, 

                 Francesco

2011/6/16 Francesco Vitale <[hidden email]>

Dear Trond, 

you asked me: «what you are using this shape for?». My aim is to store the geometric data in a SpatDIF in order to work with them for sonification and spatialization purposes. In a more general way, this could lead to what I call 3D additive synthesis. In the OM patch attached you can find some examples of what I'm trying to achieve: keep in mind that all the synthesized sounds (which are direct sonifications of the curves) are produced through the "time anamorphosis" that betrays the original forms.

                       Best, 

                  Francesco

2011/6/15 Trond Lossius <[hidden email]>

Dear Francesco,

> I think you're right. Describing a geometric shape in a SparDIF rather than «the position of a single point unfolding over time» is exactly my purpose.

If so, I can understand that stuff might get mangled. If all points in reality exists simultaneaous, at the same point in time, and the line from one point to the next need to be drawn in a specific sequence in order to render the curve correctly, I can understand that the curve might get mangled if the sequence of points get reshuffled.

At the time being I don't think we have any support (or specification for how to describe) geometric shapes. I would assume that for you to draw a geometric shape correctly, you have to draw a line from one point to the next in a specific sequence. One hackish workaround would be to introduce a delta step so that you use the time dimension as an index for organizing the sequence of the points.

Of course, if the shape itself change over time, this won't work.

May I ask what you are using this shape for? I think it would be useful to know more about the use case that you are dealing with, in order to understand what challenges and need it might call for.

Thanks,
Trond

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Francesco Vitale]

Dear Trond, 

I tried to send my message with the attachments to your address: I hope that this time you'll manage to get them. 

                               Best, 

                           Francesco

2011/6/16 Francesco Vitale <[hidden email]>

Dear Trond, 

you asked me: «what you are using this shape for?». My aim is to store the geometric data in a SpatDIF in order to work with them for sonification and spatialization purposes. In a more general way, this could lead to what I call 3D additive synthesis. In the OM patch attached you can find some examples of what I'm trying to achieve: keep in mind that all the synthesized sounds (which are direct sonifications of the curves) are produced through the "time anamorphosis" that betrays the original forms.

                       Best, 

                  Francesco

2011/6/15 Trond Lossius <[hidden email]>

Dear Francesco,

> I think you're right. Describing a geometric shape in a SparDIF rather than «the position of a single point unfolding over time» is exactly my purpose.

If so, I can understand that stuff might get mangled. If all points in reality exists simultaneaous, at the same point in time, and the line from one point to the next need to be drawn in a specific sequence in order to render the curve correctly, I can understand that the curve might get mangled if the sequence of points get reshuffled.

At the time being I don't think we have any support (or specification for how to describe) geometric shapes. I would assume that for you to draw a geometric shape correctly, you have to draw a line from one point to the next in a specific sequence. One hackish workaround would be to introduce a delta step so that you use the time dimension as an index for organizing the sequence of the points.

Of course, if the shape itself change over time, this won't work.

May I ask what you are using this shape for? I think it would be useful to know more about the use case that you are dealing with, in order to understand what challenges and need it might call for.

Thanks,
Trond

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif

[Jean Bresson]

Yes, sorry, the cylindrical and spherical coordinates are probably wrong, because I actually do not use them.
These types were mainly here to emphasize the possibility to use other systems than Cartesian; their actual contents details would probably better be modified as you say.

Jean



Le 15 juin 2011 à 23:57, Trond Lossius a écrit :

> Thanks for this link, Jean!
>
> Out of curiosity, have you decided on any coordinate system conventions for Cartesian and spherical coordinates?
>
> Apart from that, I am also wondering about the SDIF abbreviations for the following:
>
> 1MTD XCAR {x, y, z}
> 1MTD XSPH {azimuth, zenith, distance}
> 1MTD XCYL {azimuth, distance, elevation}
>
> If SPH in XSPH is an abbreviation for spherical and CYL in XCYL is short for cylindric, wouldn't the following be more appropriate?
>
> 1MTD XCAR {x, y, z}
> 1MTD XSPH {azimuth, distance, elevation}
> 1MTD XCYL {azimuth, zenith, distance}
>
> In the latter: Is "distance" describing distance in the horizontal plane, or three-dimensional distance?
>
> I'm also wondering if there is a reason why distance is set to be the 2nd element in one and the 3rd element in the other. Would it perhaps be better to organize the spherical coordinates as {azimuth, elevation, distance}, is is done in the ICST externals for Max?
>
>
> Yours,
> Trond
>
>
> On Jun 15, 2011, at 5:28 PM, Jean Bresson wrote:
>
>> Hi all,
>>
>> We've posted a few months ago a proposal for SIDF spatial descriptions of the Type Grafitti Wall of the SDIF Wiki
>> [ http://sourceforge.net/apps/mediawiki/sdif/index.php?title=SDIF_Type_Grafitti_Wall#SDIF_spatial_scenes_description ]
>>
>> These are the convention adopted in OpenMusic and the Spat for storing and interchange trajectories and other spatial descriptions.
>>
>> Jean
>>
>>
>> Le 15 juin 2011 à 10:57, Diemo Schwarz a écrit :
>>
>>>
>>> On 15.06.11 10:31, Jan Schacher wrote:
>>>> To answer some of the simpler questions you ask: In SpatDIF we have two ways
>>>> of looking at data, either frame-based or stream-based. In the frame-based
>>>> representations all events that fall on a specific time-point will be
>>>> grouped. In the stream-based version all events belonging to a specific
>>>> stream (track) will be grouped. IMHO SDIF works only in the latter paradigm
>>>> and maybe one your specific software implementations mixes up the two in an
>>>> unfortunate manner?
>>>
>>> Just to rebound on the last point: the frame-based representation would be easily represented in SDIF by using the rows of a matrix for different xyz points, but you have to make sure all points are always present.  If you want to loosen that requirement, you'd need to introduce and handle an index column (ixyz) --- that's probably better handled by streams.
>>> (I vaguely remember that this was mentioned in the g/spatdif meeting 2010, but don't know if it is in the spec).
>>>
>>> Cheers...
>>> ...Diemo
>>>
>>>
>>>> Also SpatDIF doesn't impose a fixed sampling rate / time-grid. It is up to
>>>> the software implementer to store as many time-points as necessary to
>>>> represent a trajectory faithfully.
>>>
>>> --
>>> Diemo Schwarz, PhD -- http://diemo.concatenative.net
>>> Real-Time Music Interaction Team -- http://imtr.ircam.fr
>>> IRCAM - Centre Pompidou -- 1, place Igor-Stravinsky, 75004 Paris, France
>>> Phone [phone] -- Fax [phone]
>>> _______________________________________________
>>> Spatdif mailing list
>>> [hidden email]
>>> https://mail.bek.no/mailman/listinfo/spatdif
>>>
>>
>> _______________________________________________
>> Spatdif mailing list
>> [hidden email]
>> https://mail.bek.no/mailman/listinfo/spatdif
>
> _______________________________________________
> Spatdif mailing list
> [hidden email]
> https://mail.bek.no/mailman/listinfo/spatdif
>

_______________________________________________
Spatdif mailing list
[hidden email]
https://mail.bek.no/mailman/listinfo/spatdif