[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] Record OSC



Hi Gil,

thanks for your answer, I will look into that.

best,
Marcello


On 11.12.19 04:06, gilfuser@xxxxxxxxx wrote:
> Hi Marcello
> 
> Take look at the Quark FileLog. I'm using it, mixing datatypes without
> problems.
> 
> https://github.com/supercollider-quarks/FileLog
> 
> bests,
> Gil
> 
> On Tue, Dec 10, 2019, 5:06 PM <marcello.lussana@xxxxxxxxxxxx
> <mailto:marcello.lussana@xxxxxxxxxxxx>> wrote:
> 
>     Thank you for your explanation.
>     I cannot really find where the extension try to force the float datatype
>     though, do you know which function/method is supposed to do that?
> 
> 
>     On 10.12.19 15:09, jamshark70@xxxxxxxxx
>     <mailto:jamshark70@xxxxxxxxx> wrote:
>     >
>     > On Tue, Dec 10, 2019 at 7:39 PM <marcello.lussana@xxxxxxxxxxxx
>     <mailto:marcello.lussana@xxxxxxxxxxxx>
>     > <mailto:marcello.lussana@xxxxxxxxxxxx
>     <mailto:marcello.lussana@xxxxxxxxxxxx>>> wrote:
>     >
>     >     hi all,
>     >
>     >     I am looking for a way to record and playback OSC messages.
>     >
>     >     I found a an extension on git that does exactly that:
>     >     https://github.com/sensestage/SC-OSCFileLog
>     >     Running the example in the help file, unfortunately I get an
>     error (see
>     >     below) when I try to play back the recorded file, I guess it
>     might be a
>     >     SC version problem, as this extension is 5 years old.
>     >
>     >     Are there any other known way to record and playback OSC messages?
>     >
>     >     Thanks,
>     >     Marcello
>     >
>     >     ==================
>     >
>     >     ERROR: Command line parse failed
>     >     ERROR: syntax error, unexpected INTEGER, expecting NAME or
>     WHILE or '['
>     >     or '('
>     >       in interpreted text
>     >       line 1 char 5:
>     >
>     >       0.0.0
>     >           ^
>     >
>     >
>     > SC changed so that floating-point numbers whose fraction is 0
>     (e.g. 1.0,
>     > 2.0 etc.) now always print with .0 at the end. Before, .0 was omitted.
>     >
>     > It looks like this extension is forcing a certain datatype to be
>     always
>     > float in the text representation, without checking whether the decimal
>     > point is actually missing.
>     >
>     > That's an annoyance (and developers are aware that this change, though
>     > made for a good reason, did end up breaking code) -- but it's also
>     > because of fragile code design in the extension. That is, it's correct
>     > to add .0 if a float renders as e.g. "300" (no decimal point) --
>     but the
>     > logic in the code currently doesn't check for a decimal point --
>     it says
>     > "if the fraction is zero, then there is no decimal point, so we
>     have to
>     > add one." So the extension should be updated either to remove the
>     check
>     > (which is not necessary anymore) or to use a simpler condition.
>     >
>     > hjh
> 
> 
>     _______________________________________________
>     sc-users mailing list
> 
>     info (subscription, etc.):
>     http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
>     archive: https://listarc.bham.ac.uk/marchives/sc-users/
>     search: https://listarc.bham.ac.uk/lists/sc-users/search/
> 


_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/