Fear is the crazy uncle of invention.
By The foreign staff at The Telegraph
Fear is the crazy uncle of invention.
By The foreign staff at The Telegraph
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++
(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.
Inspiration for the PLL fm detector in gen~
by SKRASMS at Cycling 74 Forums
http://cycling74.com/forums/topic/sharing-digital-pll-made-with-gen/
A Xerox machine for statues?
A more permanent medium than the video you are watching about it.
By Eric Lyon
Have been relocated to:
https://github.com/ericlyon/LyonPotpourri-MaxMSP
Object Listing: - adsr~ a simple ADSR envelope that can be click triggered - arrayfilt~ fft-based filtering by drawing into an array - bashfest~ a click driven buffer player with randomized DSP - buffet~ provides operations on a stored buffer - bvplay~ selective playback from a stored buffer with enveloping and increment control - cartopol~ convert a spectral frame from cartesian to polar form - channel~ access to a precise address in the signal vector - chopper~ munging loop playback from a buffer - clean_selector~ like selector~ but crossfades when switching channels - click~ converts a bang to a click - click2float~ translates a signal click to a float message - clickhold~ sample and hold a click - convolver~ non-real-time convolution with impulses of arbitrary size - distortion~ lookup function distortion - dmach~ pattern based sample accurate drum machine prototype - expflam~ converts a click to an exponential flam click pattern - flanjah~ simple flanger - function~ write various functions into an array - granola~ granular pitch scaling - granulesf~ granular synthesis module reading from a soundfile in a buffer - granule~ granular synthesis module reading from a stored waveform in a buffer - greater~ compares two signals on a per-sample basis - kbuffer~ low sampling rate buffer to capture gestures - killdc~ DC block filter - latch~ sustain an incoming click with sample-accurate timing - magfreq_analysis~ transforms a time domain signal to a magnitude/frequency spectrum - markov~ implements a first order Markov chain - mask~ a click driven pattern sequencer - npan~ power-panning to an arbitrary number of output channels - oscil~ oscillator with flexible waveform specification - phasemod~ phase modulated waveform - player~ click driven buffer player that can sustain multiple iterations - poltocar~ convert spectral frame from polar to complex representation - pulser~ pulse wave generated by additive synthesis - quadpan~ pan an incoming sound within a quadraphonic plane - rotapan~ rotate an array of input channels to the same number of output channels - rtrig~ generates random click triggers - samm~ sample accurate multiple metronomes, with click signal articulation - sarec~ sample accurate recording - sel~ sample-accurate implementation of the sel algorithm - shoehorn~ collapse from a larger number to a smaller number of audio channels - sigseq~ signal level numerical sequencer - splitbank~ - split an incoming sound into complementary, independently tunable spectra - splitspec~ split an incoming sound into complementary spectra - squash~ implementation of a compression algorithm by Chris Penrose - stutter~ stuttering playback from an array - vdb~ a delay line using an array for storage (no vector limit on feedback delaytime) - vdp~ a simple, self-contained delay unit - vecdex~ outputs the sample index within the current signal vector - waveshape~ a Chebychev function lookup waveshaper - windowvec~ apply a Hann window to the input signal vector
By Stefanie Blendis at CNN Money
http://money.cnn.com/video/technology/2013/01/02/t-ts-li-fi-wireless.cnnmoney/
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/
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.