Constructing midi messages from sensor data
I’m just reading you project idea.
To read a value of a sensor (mic for example) with a PIC (or Arduino)you have to read this data using an analogue input of the PIC (Arduino).
A PIC can understand values DC between 0 and 5V. An outgoing signal of a mic (it has to be preamplified)is a AC signal and can’t be interpreted by a PIC (or at least you get only some random results).
To make a readable signal for a PIC from a mic (or pressure sensor) you need to use an envelope follower.
The Arduino has 8 analogue-inputs with a 10bit resolution, 4,7mV.
Now to send this bites wireless you have to create some protocol with (8bit) bytes to tell Pd the how to interpret the incoming data flow.
In my project I send 3 bytes to Pd. The first byte is a 0X00 value to initiate a switch, the second byte is “result_hi-byte” and the third byte “result_lo-byte” of the PIC.
If the value of the analogue input trops to 0x00 (no mic pressure) a last byte with a number of the input channel is sent to Pd. In this way I can define the duration of a Note, very similar to a Note-Off message of a midi_message.
I made a program for Pd and if you want I send it to you.
To send a value of a button is much easier. A button has only the value On/Off, Yes/No, so with one byte you can define the value of 8 buttons.
In my webpage I have information about envelope followers and other things. www.drumanart.com
saludos Martin
Emulate oto biscuit in PD
@atarikai said:
So the first [expr~ int()] (which can also be a [quantize~] right?) is converting the signal from (numerically) -1 - +1 to 0 - 255. Converting it so it can be manipulated easier down the line.
The first [expr~] is only a portion of what [quantize~] does. The one at the end would be the other portion. So you can't just replace it with [quantize~]. The reason why it's converting it to integers in the range of 0-255 is because that is all that 8-bits can represent. Technically (and possibly to confuse things further) all numbers in Pd are represented in 32-bits. Using integers between 0-255 only uses the first 8-bits, while the other 24-bits are zeroed out. So this allows you to treat a 32-bit number as an 8-bit one.
he next 2 [expr~] are the inverter and muter. Would you describe what they do being 'masking' or 'filtering'? Maybe the inverter is a filter and the muter is a mask?
I would just call it distortion.
The last [expr~] is converting the 0-255 back to -1 - +1 (otherwise it wouldn't fit in the array).
Not just to fit in the array, but also to not clip your dac. With 32-bit floating point audio, the standard is to fit it in the range of -1 to 1 when it is send to the soundcard. It will then convert that range to the bit-depth your soundcard uses. Anything out of the -1 to 1 range is considered headroom for processing in Pd, but once it reaches the dac anything out of that range is clipped.
Thanks alot for building this for me. I didn't realize you could manipulate a signal this way...I thought we'd have to convert the signal to integers, manipulate the bits then convert back to a signal again.
Well, that is what we're doing, more or less! It's just "not really" integers, as explained above, but we can still treat them like integers. And technically, it's always a signal.
Emulate oto biscuit in PD
How would I get the 8 individual bits of the 8 bit signal?
8 [decimate~] objects? I didn't see in the help file if it can choose a bit, It looks like it just sets the overall bit depth you want. Would I route the [decimate~] to [hip~] or [lop~] filters to isolate the bits?
As for [swap~] the help file says that it converts the signal to 16 bit before it inverts the bits. So would I route the signal through the [swap~] then [decimate~] that to 8-bit? or vica versa?
Thanks for the tips guys!
Interfacing PD with the Arduino ... how?
i got a problem in uploading the file to the board. ( I have press play, same error found. When I press upload to I/O, below error found)
anyone can help?
thx
////////////////////////////
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:61: error: typedef 'callbackFunction' is initialized (use __typeof__ instead)
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:61: error: 'byte' was not declared in this scope
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:61: error: expected primary-expression before 'int'
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:64: error: typedef 'sysexCallbackFunction' is initialized (use __typeof__ instead)
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:64: error: 'byte' was not declared in this scope
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:64: error: 'byte' was not declared in this scope
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:64: error: 'byte' was not declared in this scope
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:64: error: 'argv' was not declared in this scope
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:81: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:81: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:86: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:87: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:88: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:90: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:91: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:91: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:91: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:95: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:95: error: 'callbackFunction' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:96: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:97: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:98: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:98: error: 'sysexCallbackFunction' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:98: error: 'void FirmataClass::attach(int, int)' cannot be overloaded
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:95: error: with 'void FirmataClass::attach(int, int)'
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:99: error: 'byte' has not been declared
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:104: error: 'byte' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:105: error: ISO C++ forbids declaration of 'byte' with no type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:105: error: expected ';' before '*' token
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:107: error: 'byte' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:108: error: 'byte' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:109: error: 'byte' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:110: error: 'byte' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:112: error: 'boolean' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:115: error: 'callbackFunction' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:116: error: 'callbackFunction' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:117: error: 'callbackFunction' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:118: error: 'callbackFunction' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:119: error: 'callbackFunction' does not name a type
/Applications/arduino-0012/hardware/libraries/Firmata/Firmata.h:122: error: 'sysexCallbackFunction' does not name a type
In function 'void setup()':
Any slicers or offset samplers in PD?
I was thinking dismissively about this today, "Crazy kids and their beat slicers..."
Then I remembered it's actualy non-trivial, in fact it can be a pig of problem to do properly.
May a suggest that it be split up into sensible software components.
The first two parts are easy really, the table manager for storing samples in arrays, flatfiles or whatever, and the resequencer or slice dumper that can nicely envelope each chunk and play it or write them all as incrementally named files somewhere.
The third part is the bitch. We need a beat detector that can find startpoints. Easy with a nice clean recording, but with the Amen beat for jungle - that's the trick. Some kind of spectral differential is called for hooked to a look-ahead and look-back inteligent zero detector. (want to catch them on a positive going phase) Crack this and you've basically done the hard work.
The sub-unit should take an arbitary sized file and return a list of indexes that correspond to the start of an event according to three or four spectral thresholds, one for high, mid and low events (hihat, snare and kick)
As an aside, I used Recycle way back, I don't know if they improved the algorithm significantly since but honestly I found it a piece of crap, really sloppy at false positives caused by clicks or dicsontinuities, really naive algorithm which always went for the minima before a beat even if it was obviously way too early. I had a production job for a band which involved a lot of beat cutting and in the end I ditched recycle and went for cutting them by hand in cool edit, much faster. Steinbergs programmers aren't idiots, which leads to me to think there's a lot to doing this well.
PureData's patchfile format
@from said:
Color: Some graphical elements have color attributes. Per color only one signed integer value is stored that contains the three 8-bit color // components (RGB). Formula to calculate color attribute values:
color = ( * -65536) + ( [green] * -256) + ( [blue] * -1)
Where [red], [green], [blue] obviously represent the three color components, their values range from 0 to 255. They apply to the attributes [background color], [front color], [label color] of various elements.
my notes on the matter:
I discovered that this formula did not produce the same values that were being in produced in the file. After a frustrating investigation into the discrepency, I realized that Pd color component values are not stored as 8-bit values. For some reason Pd scales these values down to 6-bit values. I am not sure why 6-bit values instead of 8-bit; it does not make much sense to me. The following formula produces accurate results to +/- 1 tolerance:
color = (([red]/-4 * 2^12) +([green]/-4 * 2^6) +([blue]*-1)
I am not sure why the result of this ends up one number off. I think it has to do with integer numbers being rounded when divided by four.
If you convert the decimal representation of the the RGB triplet to hexadecimal, and take the 5 least significant nibbles of that hexadecimal number, and convert each of those nibbles to binary, you can extract the 6-bit values. A binary representation looks like this:
xxrr rrrr gggg ggbb bbbb,
where each letter represents one bit. The six r's, six g's, and six b's obviously refer to the 6-bit red, green and blue values.[/blue][/green][/red][/blue][/green][/red][/blue][/green]
Announcing bagoftricks-0.2.8
hi forum.
i dunno if announcements of this kind belong to the abstractions forum, the patches one or the news one (maybe even the pd-announce mailing list?) but for i wish to share my pack of abstractions with the community, i file it under abstract~.
for those of you who use pd mainly for music synthesis, my bagoftricks might be interesting, i announced it already (0.2.6) together with that shameful electro track i posted here (yes, i can do better .
here's the new version 0.2.8:
[url=https://www.puredata.org/Members/syntax_the_nerd
]https://www.puredata.org/Members/syntax_the_nerd
from the changes.txt (since 0.2.6):
-added bot.wshaper, capable of cosine, polynomic and some other transform
-fixed pitch bug in bot.blubber, much more usable on idm drums now
-added bot.chord, simple number to harmonic group of numbers converter
-repaired a bunch of ugly bugs in bot.plucker. should be in tune now and cpu
aware
-added bot.paraeq single 2p-bandpass wrapper
-slightly changed bot.distort's behaviour
-added a volume control to bot.blip
-changed bot.filter from using bot.synth2's vcf filterboxes to regular
lp/hp/bp's. saves a lot of cpu, they weren't signal controlled anyway
-bot.revplay can now play forward. idm retriggers hooray!
-added bot.kmute, a keyboard-controlled spigot scheduler
-added "please hurt" to the bot-song-archive
-nailed down some cpu leaks
-added some cpu leaks
-added bot.pong not really finished yet, though, but fun to watch (beware, it
drains some cpu cycles)
-added a new hihat sound to bot.minidrm
-some bugs added, some fixed
-extended bot.sq-piano somewhat
-crippled bot.sq, now depends heavily on bot.sq-piano
enjoy, and don't forget to mail comments, flames or tracks to me.
stn
Compiling for x86\_64
not really a useful reply, but i'm having the same difficulties. I'm guessing that something in the source code specifically is written for the 32 architecture. For instance on a 32 bit machine integers and floats are a specific size but in a 64 bit machine that size is different. Perhaps Puckette has some variables that are created on a low level so that he has specified the size to be that which is normally used in a 32 bit environment.
Hopefully when (if) I get the time i can take a look at the source code and see if I can find anything out. A cursory look at x_gui.c says that the line in quesiton reads "sprintf(buf, "d%x", (t_int)x);" . sprintf is this buffer writting mechanism...here he is writting something into the buffer and converting it to his own type (t_int), through explicit type casting, in the process.
He defines t_int in m_pd.h where he takes care of making sure all the precompiler junk is squared away.
"#ifdef __alpha__
typedef long t_int;
#else
typedef int t_int;
#endif"
Perhaps someone with experience in multiple architectures could help...or perhaps someone wants to bug a pd-extended developer or even Puckette himself.
My guess at a solution is to get the compiler to use a 32 bit word ("word" is the term for the size a variable takes up) and not a 64 bit word for all variables. (not quite sure if this is really possible though). You might also try compiling it on a 32 bit machine and copying the whole pd directory over to your 64 and giving that a shot.
Also you may want to change the makefile so that it points entirely to ../libs64/ or entirely to ../libs/
Tabread object troubles
the 2^23 limit , from my part , ive always heard about 32 bit internal resolution , hence 2^31
A floating point number is a binary way of writing numbers like -1.462e24 or 6.444e-10 . Out of the 32 bits, 1 bit is the sign of the number, and 8 bits are for the number after the "e". That leaves 23 bits for the actual digits of the number. You only get a certain number of significant digits of precision, which means the absolute difference between adjacent floats increases as you increase the size of the float.
Say you had three decimal digits of precision. Then you could represent 1.00 - 9.99 in step 0.01. 10.0 - 99.9 in 0.1's, 100 - 999 in 1's, but after that the difference between successive numbers that you can represent is 10, so you have 1000, 1010, 1020, ... , 9980, 9990, 10000, then 100's: 10100, 10200 and the gap increases to 1000 at the next power of 10. Going the other way with smaller numbers, the absolute gap between floats gets smaller, but the relative (percentage) gap between floats stays roughly the same over the whole range of floats.
If Pd had a 32bit integer type, it could represent time up to 27 hours, if it had a double (64 bit) float type it could go even further, and if it had a 64bit integer type it could go further still. And really you want an integer type for time, because of the discrete time of sampling - then when it overflows you get an obvious error, rather than these non-failing distortions you get with float quantisation (quantisation = loss of significant digits of precision).
I think Gridflow has more types than Pd, that could be worth looking into.