headers
salsaman | 29 May 2005 12:26
Picon
Picon
Favicon

Livido latest updates

Hi,
here is an update on the latest state of livido, which we hope is now 
approaching a 1.0 proposal. This follows a meeting between Niels, 
Jaromil and I at ASCII in late April.

We decided on a hybrid approach, at the highest level (classes, channels 
and frames), we will keep as at present, structs with fields. For 
parameters we decided on a more gObject type approach - parameters are 
now simply bundles of properties. These properties will be specified per 
type ("type" is also a property)., e.g. for a numerical type parameter, 
the mandatory properties might be "type", "name", "value", "min", "max", 
"decimals", etc. There can also be optional properties (e.g. "page_size").

Properties will be stored in a linked list, and the key will be a 
string. The actual linked list implementation can be implemented by the 
host, although the livido support library should supply a default linked 
list handler.

We decided on a 3 level approach: a data level, a single-value/array 
level, and the actual property. There will be get/set stub functions 
which will call the linked list implementation. Returned/stored values 
will be void * with a length field (the data level), and will be copied 
on a get/set.

Perhaps one of the others, Niels or Jaromil can give more information, I 
need to look again at the latest livido.h before posting more technical 
details.

Regards,
Gabriel.
(Continue reading)

Permalink | Reply | 18 comments |
headers
salsaman | 30 May 2005 11:35
Picon
Picon
Favicon

Re: Livido latest updates

salsaman wrote:

> Hi,
> here is an update on the latest state of livido, which we hope is now 
> approaching a 1.0 proposal. This follows a meeting between Niels, 
> Jaromil and I at ASCII in late April.
>
> We decided on a hybrid approach, at the highest level (classes, 
> channels and frames), we will keep as at present, structs with fields. 
> For parameters we decided on a more gObject type approach - parameters 
> are now simply bundles of properties. These properties will be 
> specified per type ("type" is also a property)., e.g. for a numerical 
> type parameter, the mandatory properties might be "type", "name", 
> "value", "min", "max", "decimals", etc. There can also be optional 
> properties (e.g. "page_size").
>
> Properties will be stored in a linked list, and the key will be a 
> string. The actual linked list implementation can be implemented by 
> the host, although the livido support library should supply a default 
> linked list handler.
>
> We decided on a 3 level approach: a data level, a single-value/array 
> level, and the actual property. There will be get/set stub functions 
> which will call the linked list implementation. Returned/stored values 
> will be void * with a length field (the data level), and will be 
> copied on a get/set.
>
> Perhaps one of the others, Niels or Jaromil can give more information, 
> I need to look again at the latest livido.h before posting more 
> technical details.
(Continue reading)

Permalink | Reply | 9 comments |
headers
salsaman | 30 May 2005 12:02
Picon
Picon
Favicon

Re: Livido latest updates

salsaman wrote:

> Hi,
> here is an update on the latest state of livido, which we hope is now 
> approaching a 1.0 proposal. This follows a meeting between Niels, 
> Jaromil and I at ASCII in late April.
>
> We decided on a hybrid approach, at the highest level (classes, 
> channels and frames), we will keep as at present, structs with fields. 
> For parameters we decided on a more gObject type approach - parameters 
> are now simply bundles of properties. These properties will be 
> specified per type ("type" is also a property)., e.g. for a numerical 
> type parameter, the mandatory properties might be "type", "name", 
> "value", "min", "max", "decimals", etc. There can also be optional 
> properties (e.g. "page_size").
>
> Properties will be stored in a linked list, and the key will be a 
> string. The actual linked list implementation can be implemented by 
> the host, although the livido support library should supply a default 
> linked list handler.
>
> We decided on a 3 level approach: a data level, a single-value/array 
> level, and the actual property. There will be get/set stub functions 
> which will call the linked list implementation. Returned/stored values 
> will be void * with a length field (the data level), and will be 
> copied on a get/set.
>
> Perhaps one of the others, Niels or Jaromil can give more information, 
> I need to look again at the latest livido.h before posting more 
> technical details.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Niels Elburg | 30 May 2005 11:55
Favicon

Re: Livido latest updates


re all

On Mon, 30 May 2005, salsaman wrote:

> salsaman wrote:
>
>> Hi,
>> here is an update on the latest state of livido, which we hope is now 
>> approaching a 1.0 proposal. This follows a meeting between Niels, Jaromil 
>> and I at ASCII in late April.
>>

Yes , during my visit to jaromil we discussed a few things on Livido and 
Vevo.

>> We decided on a hybrid approach, at the highest level (classes, channels 
>> and frames), we will keep as at present, structs with fields. For 
>> parameters we decided on a more gObject type approach - parameters are now 
>> simply bundles of properties. These properties will be specified per type 
>> ("type" is also a property)., e.g. for a numerical type parameter, the 
>> mandatory properties might be "type", "name", "value", "min", "max", 
>> "decimals", etc. There can also be optional properties (e.g. "page_size").
>>

Yes, we put the values in some data structure and access them with a key.
The values are stored by copy (not by reference).
The mandatory properties depend on the type of parameter.

>>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Niels Elburg | 30 May 2005 12:01
Favicon

Re: Livido latest updates

> Ah, one final implementation detail which I missed out: properties also have 
> flags - at the moment we have only two flags - read_only_host and 
> read_only_plugin. For example when the "type" property is set, it should be 
> set read_only_host|read_only_plugin. We also decided on having wrapper 
> functions which will initialise all of the default properties for a parameter 
> in one function call.

A lot of implementation details can be found in
http://veejay.dyne.org/trac.cgi/browser/trunk/vevo-current/ :)

It is best to identify all properties (constraints and dependencies)
and work out a specification of Parameters (in a document, not in a 
programming language). We can use the livido wiki for this (jaromil?)
Some time later, we can see if you all agree on channel properties
and work out that part as well.

  Cheers

  Niels

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
http://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org
Permalink | Reply | 6 comments |
headers
Andraz Tori | 30 May 2005 12:14
Picon

Re: Livido latest updates

On pon, 2005-05-30 at 11:55 +0200, Niels Elburg wrote:

> This will eliminate a bunch of structures (beside the templates) so we
> can indeed add a property 'audiodata' to a Channel. If the channels
> would be typed we'd have audio/image/combined.

... you don't really eliminate the structures, just pack them inside the
same interface -readonly_by_host properites are in fact a replacement
for templates... 

which is completely fine.

> Secondly, it makes the system cleaner , easier to use for the programmer
> and it can be extended later to support audio.

The question i am most interested in: have you thought about how to
implement keyframing. Have you put in all the neccessary data and
interfaces to do it?

bye
andraz

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
http://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org
Permalink | Reply | 7 comments |
headers
salsaman | 30 May 2005 12:34
Picon
Picon
Favicon

Re: Livido latest updates

Andraz Tori wrote:

>On pon, 2005-05-30 at 11:55 +0200, Niels Elburg wrote:
>
>  
>
>>This will eliminate a bunch of structures (beside the templates) so we
>>can indeed add a property 'audiodata' to a Channel. If the channels
>>would be typed we'd have audio/image/combined.
>>    
>>
>
>... you don't really eliminate the structures, just pack them inside the
>same interface -readonly_by_host properites are in fact a replacement
>for templates... 
>
>which is completely fine.
>
>  
>
>>Secondly, it makes the system cleaner , easier to use for the programmer
>>and it can be extended later to support audio.
>>    
>>
>
>
>The question i am most interested in: have you thought about how to
>implement keyframing. Have you put in all the neccessary data and
>interfaces to do it?
>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andraz Tori | 30 May 2005 12:47
Picon

Re: Livido latest updates

On pon, 2005-05-30 at 12:34 +0200, salsaman wrote:
> >
> Yes, keyframing can be done exactly as at present. The main difference 
> is you are getting a property called "value" rather than the value 
> itself. And as I mentioned, this new system has an advantage that the 
> byte length of the value is also specified, so this allows for variable 
> length blob data. So the difference here is that the total data 
> length/offset may vary from frame to frame, but for any frame that 
> length/offset can always be calculated. If you ignore blob (memory ptr) 
> data, and pad/truncate strings, you end up with your current system.

I understand and I am not worried about the sizes... it is inellegant,
but i don't really care.

I am just worried wheather everything is in place to allow for keyframe
gathering callbacks and that there is basic information about timecodes
available etc.

bye
andraz

_______________________________________________
piksel-dev mailing list
piksel-dev <at> bek.no
http://plot.bek.no/mailman/listinfo/piksel-dev
http://www.piksel.org
Permalink | Reply | 5 comments |
headers
Niels Elburg | 30 May 2005 13:26
Favicon

Re: Livido latest updates


On Mon, 30 May 2005, Andraz Tori wrote:

> On pon, 2005-05-30 at 12:34 +0200, salsaman wrote:
>>>
>> Yes, keyframing can be done exactly as at present. The main difference
>> is you are getting a property called "value" rather than the value
>> itself. And as I mentioned, this new system has an advantage that the
>> byte length of the value is also specified, so this allows for variable
>> length blob data. So the difference here is that the total data
>> length/offset may vary from frame to frame, but for any frame that
>> length/offset can always be calculated. If you ignore blob (memory ptr)
>> data, and pad/truncate strings, you end up with your current system.
>
>
> I understand and I am not worried about the sizes... it is inellegant,
> but i don't really care.
>
> I am just worried wheather everything is in place to allow for keyframe
> gathering callbacks and that there is basic information about timecodes
> available etc.
>

That is quite right - not everything is in place yet

What do you mean exactly by information about timecodes being available ?

The intention is/was to use the keyframing functionality on kiberpipa.org

  - Niels
(Continue reading)

Permalink | Reply | 1 comment |
headers
salsaman | 30 May 2005 13:44
Picon
Picon
Favicon

Re: Livido latest updates

Andraz Tori wrote:

>On pon, 2005-05-30 at 12:34 +0200, salsaman wrote:
>  
>
>>Yes, keyframing can be done exactly as at present. The main difference 
>>is you are getting a property called "value" rather than the value 
>>itself. And as I mentioned, this new system has an advantage that the 
>>byte length of the value is also specified, so this allows for variable 
>>length blob data. So the difference here is that the total data 
>>length/offset may vary from frame to frame, but for any frame that 
>>length/offset can always be calculated. If you ignore blob (memory ptr) 
>>data, and pad/truncate strings, you end up with your current system.
>>    
>>
>
>
>I understand and I am not worried about the sizes... it is inellegant,
>but i don't really care.
>
>I am just worried wheather everything is in place to allow for keyframe
>gathering callbacks and that there is basic information about timecodes
>available etc.
>
>
>
>bye
>andraz
>  
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane