|
|
95a1687a5b
|
draft how a SMPTE-Timecode element could be implemented
passes Compiler, but thats about all...
|
2011-01-18 05:01:25 +01:00 |
|
|
|
71a80d3df6
|
integrate check for supported formats into Quantiser
|
2011-01-16 22:19:48 +01:00 |
|
|
|
92c4516cae
|
implement this format-support descriptor
|
2011-01-16 19:50:42 +01:00 |
|
|
|
2c90335b1d
|
WIP idea how to represent support for some timecode formats
concrete quantiser instances need a way to state
support for just some timecode formats -- yet I dont
want to push vectors aroud all over the place
|
2011-01-16 15:41:34 +01:00 |
|
|
|
eb89547265
|
get rid of the QuantiserRef
this is going to become soooo complicated
better just bite the bullet and use a shared_ptr
|
2011-01-15 00:52:02 +01:00 |
|
|
|
457d4fb7c4
|
define or stub to get it to compile; add function time-from gridnr
|
2011-01-14 05:33:50 +01:00 |
|
|
|
a1f2a60427
|
WIP design draft regarding the interplay of quantisation and timecode
|
2011-01-13 23:56:52 +01:00 |
|
|
|
e7f5ce9e33
|
WIP rework timecode format hierarchy
second try: eliminate base class,
work with concrete formats allways...
|
2011-01-13 03:36:09 +01:00 |
|
|
|
c40ba74bc6
|
WIP clarify ambiguity with fractional seconds
They are *not* intended to stand-in for gavl_time_t
Indeed, Time values should be handled as opaque
|
2011-01-13 03:36:09 +01:00 |
|
|
|
15214cc069
|
WIP start stubbing and defining time quantisation and timecode entities
|
2011-01-13 03:36:08 +01:00 |
|
