RTTY at 300+ bps in Max

notes

After a few vexing timing issues I have been able to send and decode RTTY (technically AFSK audio frequency shift keying ) in Max at 300 baud. Click hear to listen to an example of a 13 word message at 300 bps (300 baud)

The js object adds significant delays (on the order of a few milliseconds) – so I replaced the encoder with a coll and that cleaned up the timing problems when encoding. This patch demonstrates the issue:

Also… You can use threshold~ instead of snapshot~to feed binary pulse amplitude detection logic into edge~ – but you need to run the signal through average~ to prevent the amplitude from repeatedly dropping to zero at the signal frequency. Like this:

Is it better than snapshot~? it seems to be, but who knows – at these speeds it would probably be better to write the whole thing in gen~

There are a few other things – like using counter~ instead of phasor~ to drive the decoder clock. This allows you to restart the clock, when the onset of the start bit is detected – and you can add a variable amount of delay to find optimal point in the signal vector to read the pulse. At 300 bps, at 96k SR, each pulse is 320 samples (3.1 milliseconds) –

I’ll write more on this later –

The Katja Vetter article on Beat-Slicing was helpful – along with several Max tutorials on Audio control rates, and envelope followers.

Local Patches are in;

tkzic/ max teaching examples/

  • rtty-send10.maxpat
  • rtty-recv9a.maxpat

 

Leap Motion example using Cinder and c++ audio

This is a prototype from October – just getting around to posting it.

The hand position (x,y,z) is sensed by LeapMotion to control parameters of an FM synth with feedback delay written in Cinder audio (c++). The graphics were adapted from a Cinder LeapMotion demo.

Local source is in: cinder/cinder_dev/blocks/Cinder-LeapSdk/samples/LeapApp/xcode/LeapAppTZ2.xcodeproj

Uses cinder Leap demo code combined with simple audio synthesis using callbacks in c++

 

 

Applying PID control to Media coverage of politics

(photo from wikidpedia.com)

This idea came from a student, Bernardo Limon Villarreal, who suggested recording the sounds of people on the stock market trading floor – categorizing the sounds by how they match simultaneously occuring market trends , ie., optimistic, pessimistic, up, down, neutral, panic, etc.,

A speaker system feed some of these sounds back to the trading floor in an attempt to psychologically influence traders’ behavior.

Later on I started thinking about the idea of “horse race” stories in media coverage of politics. There is a theory (conspiracy) that its in the best interest of corporate media for political races to be close. So, for example, if Republicans are leading, then the “media” will air stories which favor Democrats in an effort to sway public opinion against Republicans. A continuous feedback mechanism which tries to maintain a ‘close race’.

This idea is similar to how a phase locked loop or PID controller maintains a constant temperature given varying environmental factors. It would be interesting to build a media “machine” which uses the results of opinion polls as the sensor input and always targets a 50/50 result by producing stories which with positive or negative bias, as needed.

In some ways this represents a fundamental principle of advertising.

decoding RTTY in Max

Using a local clock

(update 12/18/2013) Here is a video that shows acoustic coupling between to computers running RTTY in Max at 12.5 bits/second

Next version will have better syncing within the patch (i.e.., sample accurate timing, instead of [metro], [delay], and [snapshot]

original post

Have added stop and start bits to ascii rtty signal and reversed mark and space to the normal setting.

The current local test patches are:

tkzic/max teaching examples/

  • rtty-sim7.maxpat
  • rtty-recv7.maxpat

Accurate communication only works at very low speeds – around 11 bits/sec.  The timing on the receive side is very critical. The way it works now, is that it uses the first start bit, after a period of inactivity, to reset the clock. The ‘delay’ setting for the clock seems to be the key factor in whether the bits get read as characters.

I think that any speed increases at this point will require sample accurate timing on both send and receive sides. But as a proof of concept we have a decent start.  Its also possible that the filtering/bit detecting could be improved – but again, this is a matter now of precise timing adjustments at the sample level – and using more frequent and accurate clock adjustments on the receive side to maintain sync.

Notes on underwater sound

Not a good idea to connect a piezo directly to the output of an iPod. Apparently the impedance is too low and it fried the audio circuit and battery. I should have just dropped it (the iPod) in the water instead of the piezo.

I was able to get excellent underwater sound using  a piezo for a mic – it was a little over an inch diameter, broken out of the radio shack black plastic case – with some hot glue to cover the wire connections – probably not necessary.

See this article about working with Radio Shack piezo transducers

http://www.edrums.info/radio_shack_piezo.htm

The speaker was a Dayton Audio Weatherproof Extreme Exciter – from Amazon – http://amzn.com/B0031K2XBA

And I used a small power amp to feed it. http://amzn.com/B0049P6OT

Note: the exciter also sounds great when its duct taped to a cymbal.

 

RTTY encoding and decoding in Max

notes

Today I was able to get an AFSK (audio frequency shift keying) system running in Max – sort of – It encodes text into ASCII bits and decodes the signal back into text – with a clock set at around 30ms (32 bits/second) – but there is no clock synchronization yet. Or stop bits, etc., The patch just uses the transmitter clock to sync the receiver (cheating)

Listen to an example of the word ‘hello’ at 32 bits/sec

local file is in max teaching examples/rtty-sim5.maxpat

Next step will be to get receiver sync happening – then make it conform to RTTY standard – probably a few days effort for this, but at least this is a proof of concept.

The synchronization may need to happen at the sample level (gen~) because it requires finding the beginning and end of bits – in order to set the clock pulses accurately.

 

Ever shifting media

This morning I think about singing. And Assyrian stone reliefs.

As we hang on to the crest of evolution, media grows less permanent. Last month’s Twitter mashups are broken. The 1980’s Atrari synthesizer project gathers dust in a closet. 20th century wax cylinders locked inside museums.

Things to do. Memorize a song. Teach one to a child. This year, carve something in stone. Bury it next to a stream.

 

Laser audio

Today I built a laser pen solar panel audio transmitter thing – using these two sets of instructions – for the most part:

It works great, but I should have used a battery case instead of soldering the batteries together.

Built it into a Sparkfun box:

The next step is to experiment with filters – like an aquarium for example.

 

Osc-ruby wildcard matching

notes

The method for wildcard matching of address patterns in the osc-ruby gem has changed with upgrades to ruby 2.x

This broke the Web Audio Playground project where OSC messages get passed from Max  via Ruby via web sockets to the Web Browser.

You can use nil now for wildcard address pattern matching:

@osc_server.add_method nil do | message |

This matches every OSC message.

For more information the Web Audio Playground project, see this post: https://reactivemusic.net/?p=6193

 

 

 

ep-4xx13 DSP – week 14

Internet of things (IoT)

Big Data http://www.zdnet.com/big-data-an-overview-7000020785/ is about finding patterns in data. The IoT http://en.wikipedia.org/wiki/Internet_of_Things  allows you to make your own patterns by combining data from many sources.

Examples

Observations

  • Moral implications of ubiquitous tracking
  • A field of opportunities – connect
  • Sonification
    • parameter mapping
    • earcons
    • alarms

 Review

  1. Future music tools
  2. DSP with Max and Ableton Live
  3. Microscopic – granular synthesis
  4. Lego signals – Convolution in the frequency domain
  5. Reverse engineering, prototyping, portfolios
  6. Ideas – RJDJ environmental soundscape
  7. Sensors – cars, guitars, Csound
  8. Reversibility
  9. Artists – projects
  10. Music from the past. Internet API’s
  11. Mashups. Twitter + Max + Ruby, maps
  12. Radio waves – wrong tools
  13. Internet of Things
  14. Underwater acoustics

more about DSP

  • Google
  • Try this blog…
  • Programming (book recommendations:)
    • Curtis Roads
    • Eric Lyon
    • Dr.B
  • Software
    • Max/Pd/Csound
    • Open source projects (Web Audio API)
    • Matlab
  • Schools
  • DSP Jobs
    • (Examples from Berklee Music Network)
    • freelance work, collaboration

Topics not covered

  • programming
  • math
  • Video, graphics, optics
  • Statistics
  • Generative art
  • fiter design, impulse responses, convolution in the time domain
  • plugin design
  • Csound
  • Radar
  • Medical
  • Communciations
  • Information theory

Success

  • memory + creative confidence
  • persistence and habit
  • know yourself
  • make connections
  • save your ideas

tricks

  • Extremes – try doing way more or way less in some way, opposites, black humor
  • Abstraction – make the tool that makes something
  • Use the wrong tools
  • connect things
  • find mentors and partners
  • feed your imagination
  • start where others leave off
  • Use the entire piano