data-logger

tim vets

unread,

Jun 25, 2015, 1:43:33 PM6/25/15

to axolot...@googlegroups.com

Hi all,
I'm trying to make a data-logger with table/save.
below* is my first attempt, using a ctrl/dial b for testing
I'm using table/record to put the data in the table, which is overkill, since strictly speaking I would only need it to be K-rate (3kHz).
However, I tried other methods, using an lfo to generate indexes for table/write, and another one to generate triggers for it.
With that method, some data points in the table are skipped, probably because the triggers aren't fast enough (max. freq. lfo?).
Anyhow, all that aside (I'm going with the table/record method for now), the next thing is to parse the recorded files afterwards.
I tried it two ways so far:
1) using python, read the file and convert the hex bytes to decimal integers using basically this:
o=[ord(c) for c in my_input_file]
which gives me a list of decimal numbers, which I then interpret as 4-tuplets representing 32-bit values, like so:
for i,j,k,l in zip(o[0::4], o[1::4],o[2::4],o[3::4]):
oo.append(i+j*255+k*255*255+l*255*255*255)
2) import the recorded files as raw audio file in Audacity, but there I'm not sure which options to pick:

none of the variations I tried so far result in something in which I recognize the movements the ctrl/knob b made...
can someone with a better understanding of the encoding of these files give some input?
thanks!
Tim

* test patch:

<patch>
   <obj type="lfo/square" sha="2619a1d94a07bf82a1e47e4e34485e9c4916cc18" name="square_1" x="70" y="56">
      <params>
         <frac32.s.map name="pitch" value="-64.0"/>
      </params>
      <attribs/>
   </obj>
   <obj type="ctrl/dial b" sha="589b835807a3b8c8b05793bc4bd9adaf853f9705" name="dial_1" x="182" y="56">
      <params>
         <frac32.s.map name="value" value="-27.0"/>
      </params>
      <attribs/>
   </obj>
   <obj type="conv/interp" sha="5a9175b8d44d830756d1599a86b4a6a49813a19b" name="interp_1" x="266" y="56">
      <params/>
      <attribs/>
   </obj>
   <obj type="table/record" sha="a11cd48fc41465d055106b87f9d341f6750abf93" name="record_1" x="350" y="56">
      <params/>
      <attribs>
         <objref attributeName="table" obj="alloc_1"/>
      </attribs>
   </obj>
   <obj type="logic/counter" sha="77a4b4804913310c0ec3fcc53592eed1cd9af148" name="counter_1" x="490" y="56">
      <params>
         <int32 name="maximum" value="999"/>
      </params>
      <attribs/>
   </obj>
   <obj type="string/indexed" sha="4c1c90721e5f530e9fbdcfa373edaffe908e605b" name="indexed_1" x="588" y="56">
      <params/>
      <attribs>
         <table attributeName="prefix" table="dlog"/>
         <table attributeName="suffix" table=".log"/>
      </attribs>
   </obj>
   <obj type="table/save" sha="a722ebfda4ff4eac184af7cba9f84968d501a6bc" name="save_1" x="770" y="56">
      <params/>
      <attribs>
         <objref attributeName="table" obj="alloc_1"/>
      </attribs>
   </obj>
   <obj type="table/alloc 32b sdram" sha="4487420212d1a826e25aa61cd5abdc0238ea3207" name="alloc_1" x="910" y="56">
      <params/>
      <attribs>
         <combo attributeName="size" selection="524288"/>
         <text attributeName="init">
            <sText><![CDATA[]]></sText>
         </text>
      </attribs>
   </obj>
   <nets>
      <net>
         <source name="square_1 wave"/>
         <dest name="save_1 trig"/>
         <dest name="counter_1 trig"/>
         <dest name="record_1 trig"/>
      </net>
      <net>
         <source name="counter_1 o"/>
         <dest name="indexed_1 index"/>
      </net>
      <net>
         <source name="indexed_1 out"/>
         <dest name="save_1 filename"/>
      </net>
      <net>
         <source name="interp_1 o"/>
         <dest name="record_1 wave"/>
      </net>
      <net>
         <source name="dial_1 out"/>
         <dest name="interp_1 i"/>
      </net>
   </nets>
   <notes><![CDATA[]]></notes>
</patch>

tim vets

unread,

Jun 25, 2015, 2:08:07 PM6/25/15

to axolot...@googlegroups.com

update:
I guess you should use a smaller table, and maybe 16-bit instead of 32, so that the dsp doesn't get interrupted by the writing operations
here's an updated patch, with a test tone, to verify that there are no hickups.
it uses a table size of 8192, and writes a new file every 170.6 msec (~8192/48)

<frac32.s.map name="pitch" value="2.239999294281006"/>

   </obj>
   <nets>
      <net>
         <source name="square_1 wave"/>
         <dest name="save_1 trig"/>
         <dest name="counter_1 trig"/>
         <dest name="record_1 trig"/>
      </net>
      <net>
         <source name="counter_1 o"/>
         <dest name="indexed_1 index"/>
      </net>
      <net>
         <source name="indexed_1 out"/>
         <dest name="save_1 filename"/>
      </net>
      <net>
         <source name="interp_1 o"/>
         <dest name="record_1 wave"/>
      </net>
      <net>
         <source name="dial_1 out"/>
         <dest name="interp_1 i"/>
      </net>

      </net>
   </nets>
   <notes><![CDATA[]]></notes>
</patch>

gr,
Tim

Johannes Taelman

unread,

Jun 25, 2015, 2:08:15 PM6/25/15

to tim vets, axolot...@googlegroups.com

On Thu, Jun 25, 2015 at 7:43 PM, tim vets <tim...@gmail.com> wrote:

Hi all,
I'm trying to make a data-logger with table/save.
below* is my first attempt, using a ctrl/dial b for testing
I'm using table/record to put the data in the table, which is overkill, since strictly speaking I would only need it to be K-rate (3kHz).
However, I tried other methods, using an lfo to generate indexes for table/write, and another one to generate triggers for it.
With that method, some data points in the table are skipped, probably because the triggers aren't fast enough (max. freq. lfo?).

logic/counter could generate table indexes for table/write without skipping indexes.

Trigger the counter with an lfo/square. You can obtain higher frequencies by using the frequency inlet + frequency parameter

Anyhow, all that aside (I'm going with the table/record method for now), the next thing is to parse the recorded files afterwards.
I tried it two ways so far:
1) using python, read the file and convert the hex bytes to decimal integers using basically this:
o=[ord(c) for c in my_input_file]
which gives me a list of decimal numbers, which I then interpret as 4-tuplets representing 32-bit values, like so:
for i,j,k,l in zip(o[0::4], o[1::4],o[2::4],o[3::4]):
oo.append(i+j*255+k*255*255+l*255*255*255)

Don't know python. But 256 'd be a better number. The order is also probably wrong
oo.append(l+k*256+j*256*256+i*256*256*256)

2) import the recorded files as raw audio file in Audacity, but there I'm not sure which options to pick:

signed 32 bit integer format if your table is 32 bit

signed 16 bit integer format if your table is 16 bit

Johannes Taelman

unread,

Jun 25, 2015, 2:20:01 PM6/25/15

to tim vets, axolot...@googlegroups.com

On Thu, Jun 25, 2015 at 8:08 PM, tim vets <tim...@gmail.com> wrote:

update:
I guess you should use a smaller table, and maybe 16-bit instead of 32, so that the dsp doesn't get interrupted by the writing operations
here's an updated patch, with a test tone, to verify that there are no hickups.
it uses a table size of 8192, and writes a new file every 170.6 msec (~8192/48)

table/write will very likely cause a hickup!

https://github.com/JohannesTaelman/axoloti/issues/31

but even when this issue is resolved and table/write is threaded out, don't write to the table while the table is being written to disk

So you'd need two tables and swap between them. Now that asks for a dedicated object to stream data logs rather than patchwork.

tim vets

unread,

Jun 25, 2015, 2:41:18 PM6/25/15

to axolot...@googlegroups.com, tim...@gmail.com

Ok, thanks for your response.
In that last version, I don't notice any audible hickups.
gr,
Tim

Reply all

Reply to author

Forward