[FFmpeg-soc] [soc] libavsequencer [PATCH 04/08] Track / pattern handling public API header file.

Sebastian Vater cdgs.basty at googlemail.com
Sat Aug 14 15:14:40 CEST 2010


Vitor Sessak a écrit :
> On 08/13/2010 10:28 PM, Sebastian Vater wrote:
>> Vitor Sessak a écrit :
>>> On 08/07/2010 09:46 PM, Sebastian Vater wrote:
>>>> Vitor Sessak a écrit :
>>>>> On 07/13/2010 10:57 PM, Sebastian Vater wrote:
>>>>>> Vitor Sessak a écrit :
>>>>>>> On 07/13/2010 09:35 PM, Sebastian Vater wrote:
>>>>>>>> Vitor Sessak a écrit :
>>>>>>>>> On 07/11/2010 10:07 PM, Sebastian Vater wrote:
>>>>>>>>>> typedef struct AVSequencerTrackData {
>>>
>>> [...]
>>>
>>>>>>>>> if (instrument == previous_instrument) {...}
>>>>>>>>
>>>>>>>> Please note that instrument number 0 also differs whether you
>>>>>>>> play the
>>>>>>>> track in once mode (pattern play mode) and the instrument
>>>>>>>> number was
>>>>>>>> initialized in the previous order. All trackers don't output
>>>>>>>> sound in
>>>>>>>> that case, changing this would make this part incompatible.
>>>>>>>
>>>>>>> That's another good point, so I'm fine with instrument==0 meaning
>>>>>>> last
>>>>>>> instrument. But if the behavior of setting instrument==0 is
>>>>>>> different
>>>>>>> of the behavior of setting instrument==last_instrument, it
>>>>>>> should be
>>>>>>> documented somewhere.
>>>>>>
>>>>>>>> TrackData is the octave, note, effect and effect data for each
>>>>>>>> row,
>>>>>>>> Track itself defines the structure containing it, i.e. number of
>>>>>>>> rows,
>>>>>>>> maybe track name, etc.
>>>>>>>
>>>>>>> Maybe AVSequencerRowData then?
>>>>>>
>>>>>> Nice name, will think on it!
>>>
>>> So?
>>
>> AVSequencerTrackRow?
>>
>> Just to make the hierarchy clearer...agree on this?
>
> yes.

Fixed.

>
>>>>>>>>
>>>>>>>> This would require extending using 0x80-0xFF command effect which
>>>>>>>> would
>>>>>>>> conflict with synth sound handling (see there at the synth sound
>>>>>>>> instructions).
>>>>>>>
>>>>>>> Ok, let me pose the question differently. Suppose we have an effect
>>>>>>> foo. In MOD, effect foo is command 0x66 while in XM it is command
>>>>>>> 0x55. What is the value of AVSEQ_TRACK_EFFECT_CMD_FOO? Or such
>>>>>>> thing
>>>>>>> never happens?
>>>>>>
>>>>>> This happens very frequently, esp. between MOD/XM<=>    S3M/IT.
>>>>>> But this is part of the demuxer to convert the origins...
>>>>>
>>>>> Sure, but then doing as you do:
>>>>>
>>>>>       /** 0x66 - Do foo to stuff */
>>>>>        #define AVSEQ_TRACK_EFFECT_CMD_FOO 0x66
>>>>>
>>>>> is confusing and misleading in comparison with
>>>>>
>>>>>       /** Do foo to stuff */
>>>>>        #define AVSEQ_TRACK_EFFECT_CMD_FOO 0x66
>>>
>>> So?
>>
>> Sorry, don't understand here, what you mean.
>
> I mean that if the choice of 0x66 for AVSEQ_TRACK_EFFECT_CMD_FOO is
> merely a convention, it should not be reinforced in the comment.

Fixed.

>
>>>> diff --git a/libavsequencer/track.h b/libavsequencer/track.h
>>>> new file mode 100755
>>>> index 0000000..cf131af
>>>> --- /dev/null
>>>> +++ b/libavsequencer/track.h
>>>> @@ -0,0 +1,1636 @@
>>>> +/*
>>>> + * AVSequencer track and pattern management
>>>> + * Copyright (c) 2010 Sebastian Vater<cdgs.basty at googlemail.com>
>>>> + *
>>>> + * This file is part of FFmpeg.
>>>> + *
>>>> + * FFmpeg is free software; you can redistribute it and/or
>>>> + * modify it under the terms of the GNU Lesser General Public
>>>> + * License as published by the Free Software Foundation; either
>>>> + * version 2.1 of the License, or (at your option) any later version.
>>>> + *
>>>> + * FFmpeg is distributed in the hope that it will be useful,
>>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>>> + * Lesser General Public License for more details.
>>>> + *
>>>> + * You should have received a copy of the GNU Lesser General Public
>>>> + * License along with FFmpeg; if not, write to the Free Software
>>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>>> 02110-1301 USA
>>>> + */
>>>> +
>>>> +#ifndef AVSEQUENCER_TRACK_H
>>>> +#define AVSEQUENCER_TRACK_H
>>>> +
>>>> +#include "libavutil/log.h"
>>>> +#include "libavformat/avformat.h"
>>>> +
>>>
>>>
>>>> +/**
>>>> + * Song track effect structure, This structure is actually for one
>>>> row
>>>> + * and therefore actually pointed as an array with the amount of
>>>> + * rows of the whole track.
>>>> + * New fields can be added to the end with minor version bumps.
>>>> + * Removal, reordering and changes to existing fields require a major
>>>> + * version bump.
>>>> + */
>>>> +typedef struct AVSequencerTrackEffect {
>>>> +    /** Effect command byte.  */
>>>> +    uint8_t command;
>>>
>>> enum...
>>
>> Again where's the problem? enums are all above.
>>
>>>
>>>> +    /** Effect command data word.  */
>>>> +    uint16_t data;
>>>> +} AVSequencerTrackEffect;
>>>> +
>>>> +/** AVSequencerTrackEffect->note values.  */
>>>> +enum AVSequencerTrackDataNote {
>>>> +    /** ---  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_NONE          = 0,
>>>> +
>>>> +    /** C-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_C             = 1,
>>>> +
>>>> +    /** C#n = Dbn  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_C_SHARP       = 2,
>>>> +
>>>> +    /** D-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_D             = 3,
>>>> +
>>>> +    /** D#n = Ebn  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_D_SHARP       = 4,
>>>> +
>>>> +    /** E-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_E             = 5,
>>>> +
>>>> +    /** F-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_F             = 6,
>>>> +
>>>> +    /** F#n = Gbn  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_F_SHARP       = 7,
>>>> +
>>>> +    /** G-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_G             = 8,
>>>> +
>>>> +    /** G#n = Abn  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_G_SHARP       = 9,
>>>> +
>>>> +    /** A-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_A             = 10,
>>>> +
>>>> +    /** A#n = Bbn  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_A_SHARP       = 11,
>>>> +
>>>> +    /** B-n = H-n  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_B             = 12,
>>>> +
>>>> +    /** ^^^ = note kill  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_KILL          = -1,
>>>> +
>>>> +    /** ^^- = note off  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_OFF           = -2,
>>>> +
>>>> +    /** === = keyoff note  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_KEYOFF        = -3,
>>>> +
>>>> +    /** -|- = hold delay  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_HOLD_DELAY    = -4,
>>>> +
>>>> +    /** -\- = note fade  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_FADE          = -5,
>>>> +
>>>> +    /** END = pattern end marker  */
>>>> +    AVSEQ_TRACK_DATA_NOTE_END           = -16,
>>>> +};
>>>
>>> Why hardcoding values? Why not just use:
>>>
>>> /** AVSequencerTrackEffect->note values.  */
>>> enum AVSequencerTrackDataNote {
>>>      /** ---  */
>>>      AVSEQ_TRACK_DATA_NOTE_NONE,
>>>
>>>      /** C-n  */
>>>      AVSEQ_TRACK_DATA_NOTE_C,
>>>
>>>      /** C#n = Dbn  */
>>>      AVSEQ_TRACK_DATA_NOTE_C_SHARP,
>>>
>>>      [...]
>>> }
>>>
>>> And let the compiler assign whatever numbers it seems fit?
>>
>> Would require every demuxer/muxer to convert these values if they don't
>> match,
>
> Every format uses the same convention?

For the positive notes, this is the case, as far as I know. For the
negative special note effects it differs. But most use negative values,
too, if I remember correctly, so you know it's a special note by just
checking for < 0.

Anyway, I fixed this by removing the 1 to 12 assignments and just set
NONE to 0, the compiler automatically always adds one in a subsequent
enum, right?

This is required, since the player uses a lut for calculating the target
frequency which is base_freq * (octave - 4) * 2^((note - 1)/12).

-- 

Best regards,
                   :-) Basty/CDGS (-:



More information about the FFmpeg-soc mailing list