Add track display view to AUP

[Edgar]

How about this:

Code: Select all

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE project PUBLIC "-//audacityproject-1.3.0//DTD//EN" "http://audacityteam.org/xml/audacityproject-1.3.0.dtd" >
<project xmlns="http://audacityteam.org/xml/" projname="ab_data" version="1.3.0" audacityversion="2.0.7-alpha-Oct 28 2014" sel0="0.3394181403" sel1="0.6702795208" vpos="0" h="0.0000000000" zoom="350.6000000000" rate="44100.0" snapto="off" selectionformat="hh:mm:ss + hundredths">
	<tags/>
	<wavetrack name="Audio Track" channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0" waveTrackDisplay="0">
		<wavetrack_display_type is="Waveform Display"/>
		<waveclip offset="0.00000000">
			<sequence maxsamples="262144" sampleformat="262159" numsamples="220500">
				<waveblock start="0">
					<simpleblockfile filename="e0000bd8.au" len="220500" min="-0.799729" max="0.799916" rms="0.319909"/>
				</waveblock>
			</sequence>
			<envelope numpoints="0"/>
		</waveclip>
	</wavetrack>
</project>

<wavetrack_display_type is="Waveform Display"/>
Note that the original element waveTrackDisplay="0" Is what does the real work, the new attribute wavetrack_display_type is only written not read.

Patch attached

[Edgar]

bump…

Since we only have a couple of days before the freeze deadline, and I personally prefer it, I would go with the patch in the very first post of this thread.

[steve]

Knowing that you are a stickler for detail If the track display is part of the project, then strictly speaking, changing the display of a track "changes the project". So if I open a project and change the view of a track, then the project is now different. So why am I not able to use "File > Save Project" to save the change? Same for project rate, time format and Snap To state.

[Edgar]

Knowing that you are a stickler for detail ;) If the track display is part of the project, then strictly speaking, changing the display of a track "changes the project". So if I open a project and change the view of a track, then the project is now different. So why am I not able to use "File > Save Project" to save the change? Same for project rate, time format and Snap To state.

This is the very first bug I ever reported - years ago, it may well be on Bugzilla. I think Gale/Bugzilla has a patch which I created at that time and is obviously stale. I just looked at the patch last week but now, on cursory search - no time today, cannot find it <shrug>.

[Gale Andrews]

I think there are 30 days in November so I don't know what freeze happens in two days.

How about this:

Code: Select all

<?xml version="1.0" standalone="no" ?>
<!DOCTYPE project PUBLIC "-//audacityproject-1.3.0//DTD//EN" "http://audacityteam.org/xml/audacityproject-1.3.0.dtd" >
<project xmlns="http://audacityteam.org/xml/" projname="ab_data" version="1.3.0" audacityversion="2.0.7-alpha-Oct 28 2014" sel0="0.3394181403" sel1="0.6702795208" vpos="0" h="0.0000000000" zoom="350.6000000000" rate="44100.0" snapto="off" selectionformat="hh:mm:ss + hundredths">
	<tags/>
	<wavetrack name="Audio Track" channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0" waveTrackDisplay="0">
		<wavetrack_display_type is="Waveform Display"/>
		<waveclip offset="0.00000000">
			<sequence maxsamples="262144" sampleformat="262159" numsamples="220500">
				<waveblock start="0">
					<simpleblockfile filename="e0000bd8.au" len="220500" min="-0.799729" max="0.799916" rms="0.319909"/>
				</waveblock>
			</sequence>
			<envelope numpoints="0"/>
		</waveclip>
	</wavetrack>
</project>

<wavetrack_display_type is="Waveform Display"/>
Note that the original element waveTrackDisplay="0" Is what does the real work, the new attribute wavetrack_display_type is only written not read.

Patch attached

To me the wavetrack_display_type is redundant.

Using an attribute of the <wavetrack> element as Steve suggested:

Code: Select all

<wavetrack name="Audio Track" WaveTrackDisplay="SpectrumDisplay" channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0">

seems neat enough to me.

Why is it better to use a number than a name for the WaveTrackDisplay value?


Gale

[Edgar]

I think there are 30 days in November so I don't know what freeze happens in two days.

Why is it better to use a number than a name for the WaveTrackDisplay value?

Sorry, "couple of days" was a bit of hyperbole:

we will freeze new features on Dec 1.

I think this is a new feature.

Using a number requires only a couple of lines of new code. Currently the type-of-display is stored and manipulated in the code as a number; there is no place in the code which relates these numbers to human readable names. To do so we will need to create a way of translating these numbers into human readable strings, storing them in the AUP, retrieving them from the AUP, converting the strings into type numbers (e.g. Wave = 0, Spectrum = 1 etc.) then making sure that if a new type-of-track is ever added all of this code is updated so that it is translated, stored, converted etc.; this is not the case if we stick with the numbers - if a new numeric type is added the code still works with no changes. The only possible reason to store a human-readable string in the AUP is to aid in sophisticated debugging by experienced elves were quite capable of identifying to what the numeric value relates.

[steve]

this is not the case if we stick with the numbers - if a new numeric type is added the code still works with no changes.

Shouldn't we still check that the number is within a valid range? What happens if the AUP file has WaveTrackDisplay set to "103"?

The only possible reason to store a human-readable string in the AUP is to aid ...

but isn't that one of the main points to using XML - it is human readable as well as machine readable?
Computers are supposed to do the drudge work for the benefit of humans, not the other way round, so although it may not be programmatically elegant to write WaveTrackDisplay="Spectrum", I prefer the prioritization of humans over machines

[steve]

To do so we will need to create a way of translating these numbers into human readable strings,

writing tha AUP in pseudo code:

Code: Select all

if (display() == WaveformDisplay) write("wave");
else
if (display() == WaveformDBDisplay) write("wavedb");
else
if (display() == SpectrumDisplay) write("spectrum");
....

and reading the AUP in pseudo code:

Code: Select all

if (wavetrack, wave) SetDisplay(WaveformDisplay);
else
 if (wavetrack, wavedb) SetDisplay(WaveformDBDisplay);
else
if (wavetrack, spectrum) SetDisplay(SpectrumDisplay);
....

storing them in the AUP,

We need to write the value in the AUP whether it is an integer written as a string, or a string written as a string.

retrieving them from the AUP

We need to read the value from the AUP whether it is an integer written as a string, or a string written as a string.

converting the strings into type numbers

That doesn't appear to be difficult - not very elegant I agree, but not difficult.

then making sure that if a new type-of-track is ever added all of this code is updated

an additional "else if" added to each of the above?

so that it is translated

We don't translate XML attributes or values.

stored, converted etc

Stored where? Converted to what? Isn't that all handled by adding a new "else if" to each of the conversions above?

this is not the case if we stick with the numbers - if a new numeric type is added the code still works with no changes.

Yes, it will save adding a couple of lines if a new wavetrack view is invented.
And yes, it could save having a bug if the developer forgets to update it (as has occurred with writing "SnapTo" as "on" or "off" and then adding a third state).

I agree that there are pros and cons, but I don't see a particularly strong case either way.

[Gale Andrews]

FWIW, I would slightly favour

Code: Select all

<wavetrack name="Audio Track" WaveTrackDisplay="0" " channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0">

over

Code: Select all

<wavetrack name="Audio Track" WaveTrackDisplay="SpectrumDisplay" channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0">

given the first seems a little more maintainable.

We don't have channel="mono" linked="no" in the AUP.

I notice changing channel from "2" to "7" in the AUP causes orphan block files but we don't have error checking for that, and there is still the question what happens if Audacity encounters a human-readable typo like WaveTrackDisplay="SpectruDisplay".

I'm fine with either of the above, irrespective.

Gale

[steve]

FWIW I slightly favour:

Code: Select all

<wavetrack name="Audio Track" WaveTrackDisplay="Spectrum" channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0">

over

Code: Select all

<wavetrack name="Audio Track" WaveTrackDisplay="0" " channel="2" linked="0" mute="0" solo="0" height="150" minimized="0" isSelected="1" rate="44100" gain="1.0" pan="0.0">

given that it is more readable (and as far as I'm aware, not documented in the manual).

We don't have channel="mono" linked="no" in the AUP.

No, but we do have snapto="off" and selectionformat="hh:mm:ss + milliseconds"
We also have the rather cryptic sampleformat="262159"
All in all, the approach is quite inconsistent, so I've asked on ~devel which approach they would prefer.

and there is still the question what happens if Audacity encounters a human-readable typo like WaveTrackDisplay="SpectruDisplay".

What should happen is that it falls back to the default (Waveform).