[ 
http://dev.sourcefabric.org/browse/LS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=27145#action_27145
 ] 

David Baelde commented on LS-634:
---------------------------------

Yes, I think a #define would be cleaner. Right now, the semantics of your patch 
is unclear -- in particular, it looks like it doesn't respect scoping at all.

(Regarding your comment on stereo, I agree with you. I said this because it may 
be what Airtime does currently -- it seems like the simplest solution to avoid 
typing issues. Anyway, my suggestion to produce a more structured config script 
is independent of that aspect. It still seems like a valid idea to me, but 
adding a #define feature seems useful in any case.)

We could possibly use the pp preprocessor to process our #include and #define, 
but it's okay to do it ourselves and avoids a dependency which might be tricky 
on windows.

One trick is to clarify what #define would mean. Would it be textual 
substitution anywhere in the text, or substitution of particular variables? 
Also, the interaction between #define and the current #ifdef will be a bit 
funny since the latter is about toplevel variable definitions, nothing #defined 
things.

> Allow some variables in encoding formats
> ----------------------------------------
>
>                 Key: LS-634
>                 URL: http://dev.sourcefabric.org/browse/LS-634
>             Project: Liquidsoap
>          Issue Type: New Feature
>          Components: Liquidsoap
>            Reporter: Samuel Mimram
>
> We should allow some simple variables in encoding formats, otherwise some 
> users (airtime) are starting to get an exponential blowup in the size of 
> their scripts... I think that an easy solution would be to replace the 
> variables by their value at preprocessing time (we don't want to have a value 
> environment when doing type inference, so it has to be resolved before that).
> For instance, Martin Konečný reported this on the ML:
> The reason I brought this up, is because currently our code is as follows:
>         output_mono = (...)
>         output_stereo = (...)
>         if type == "mp3" then
>             if bitrate == 24 then 
>                 if stereo then
>                     ignore(output_stereo(%mp3(bitrate = 24, stereo = true), 
> !source))
>                 else
>                     ignore(output_mono(%mp3(bitrate = 24, stereo = false), 
> mean(!source)))
>                 end
>             elsif bitrate == 32 then
>                 if stereo then
>                     ignore(output_stereo(%mp3(bitrate = 32, stereo = true), 
> !source))
>                 else
>                     ignore(output_mono(%mp3(bitrate = 32, stereo = false), 
> mean(!source)))
>                 end
>             elsif bitrate == 48 then
>                 if stereo then
>                     ignore(output_stereo(%mp3(bitrate = 48, stereo = true), 
> !source))
>                 else
>                     ignore(output_mono(%mp3(bitrate = 48, stereo = false), 
> mean(!source)))
>                 end
> Multiply for all bitrates up to 320kbps, then once again for %vorbis, and 
> then once again for shoutcast :)
> Right now it's not so bad, but in the future if we add one more user 
> customizable variable, it would be wiser to use a code generator :)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://dev.sourcefabric.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Savonet-devl mailing list
Savonet-devl@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/savonet-devl

Répondre à