3 May
2008
3 May
'08
10:24 p.m.
On Sat, May 3, 2008 at 4:19 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
Mark Knecht wrote:
Hi Rui,
You know me pretty well at this point old friend. I've just a user.
Nothing more. I might be a pretty smart user, but I'm just a user.
As I remember the work Erik and I were doing, I think we were doing
sort of hunt and peck. I'd try a few loop files, look at the results
and if they weren't correct (as per Acid) then I'd send him info like
the stuff above, and maybe a loop file or two. I'd tell him what Acid
Pro was telling me, and he'd try and find that info in the file. He'd
do some changes and I'd try the new version via patches he'd give me.
We made some headway but eventually he ran out of time and it didn't
move forward anymore I'm actually not sure if it ever improved after
that. I've been subscribed to this list or its predecessor for over 8
years now and cannot remember any serious discussions in public.
Fankly though, without someone like you doing an app like qtractor it
didn't matter too much and I let it drop.
The need for this info is all driven by the app you're doing. I
don't know of any other Linux app that would really require it. Other
could use it but I think an app like qtractor would really make good
use if we could work it all out.
So, to the extent that you or some other developer reading this in
lurk mode has an interest I have gigabytes of Acid loops that we use
here for composition. I'd be happy to help out again should the need
arise. Having an Open Source replacement for Acid has been high on my
wish list for years. I'd love to help it happen.
Cheers,
Mark
<SNIP>
> data : 2605292
> acid : 24
> Flags : 0x0002 (Loop,RootNoteValid,StretchOff,RAMBased,??Off)
> Root note : 0x36
> ???? : 0xFFFF8000
> ???? : 0.000000
> Beats : 32
> Meter : 4/4
> Tempo : 120.000000
> strc : 4636
> *** str2 : 20 (unknown marker)
> *** bmrk : 7024 (unknown marker)
> *** dtbt : 520 (unknown marker)
> LIST : 82
> INFO
> *** MRAT : 4
> ICOP : (c) 2008 Sony Creative Software Inc. All rights reserved.
> *** mudp : 1612 (unknown marker)
> End
>
<SNIP>
thanks for the info Mark
from a cursory look this sndfile-info output is being returned as plain
text and thus unstructured, programmatically via
sf_command(SFC_GET_LOG_INFO); which seems bizarre :/
is it really supposed to parse the text string literally? or is there some
other way to read the meta-data in some structured way?
fyi, SFC_GET_LOG_INFO command is supposed to "Retrieve the internal
per-file operation log." not any meta-data, but Erik should know better ;)