@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.

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!

oh and if you did manage to find an OSC output from the liveOSC scripts, you would then need to call your LED the same as the OSC command from live, or you would need to reformat the command from live using puredata to that of the LED.

e.g. if LiveOSC has an OSC send called /live/tempo/beat (I doubt it does) then you would have LiveOSC script connect to your TouchOSC, and the LED would be also /live/tempo/beat.

It may be that even if there's no way to send OSC tempo beat messages from Live using the liveosc script, you could maybe use live to map the beat to move a controller, and send this information to puredata where you could reformat it.

I just checked http://github.com/willrjmarshall/AbletonDJTemplate/blob/44609dbd1be136d517c420f14fc987e9aa96fcc6/TouchOSCTemplate/LiveOSC/OSCAPI.txt

There isn't anything that will solely broadcast beats over OSC, but there are a couple of things that with some puredata manipulation might be able to do this:

live/tempo = Request current tempo, replies with /live/tempo (float tempo)

/live/tempo (float tempo) = Set the tempo, replies with /live/tempo (float tempo)

/live/time = Request current song time, replies with /live/time (float time)

/live/time (float time) = Set the time , replies with /live/time (float time)

It might (just) be possible to write code to examine the song tempo, examine regularly the song time and from there calculate when the beat will drop. I'm not about to start on this any time soon but there is the potential to do this. The amount of work might be offset by actually monitoring the metronome, or just listening to the music to get an idea where the bars are ;o)

Just guesses but good luck with it, I want to do similar as I'm working on a full remote DJ tool for TouchOSC (clip browser and selecter, tempo, monitoring, mixer, xfader, effects and filters). I'm using puredata for this, touchOSc and the l;iveOSC remote scripts. I tested all the theoretical bits for this and have it working, just need to but the behemoth PD together to handle it all! Oh, and another feature will be a toggle on the accelerometer to control any effect, fader etc so "put your hands in the air" and "drop the bass" will be actually doable! Of course, the main reason I want this is I like the music I spin and I'm sick of being stuck behind sensitive equipment where I can't dance properly

Hey man, this is nice! I actually started work on a [bonk~] based slicer a few months ago and got a little side-tracked with school. Hopefully I'll be able to get back to it soon and post it up.

Anyway, I mention this because I thought you might be interested in a little trick I used to get accurate beat detections. When the analysis is run, it uses the number of samples taken between the start of the analysis and the first beat detected and subtracts it from the sample numbers detected from every beat. It essentially auto-offsets the beat markers by the amount of [bonk~]'s delay. Doing this, I've found that beat detections are usually never off by more than just a few samples!

The reason why it's not working until you open [wrap~]'s help window is because audio needs to be turned on. The help patch does this automatically with:

[loadbang]
|
[; pd dsp 1(

So I'll try to explain how this patch works. It's based on using a master [phasor~] object for everything to sync to. I used beats per minute because Hz is the same thing as cycles per second. By dividing bpm by 60, you get beats (cycles) per second. It's just easier math (to me) than using ms, and it's more musically intuitive anyway.

The signal for the [phasor~] is multiplied by the beat division, scaling its range. So if you want the beat divided into four subdivisions (16th notes), it will be scaled up from 0-1 to 0-4. [wrap~] takes a signal and wraps it around so that it falls within a range of 0-1, so 2.3 will become .3, etc. It essentially just gives you the fractional part of a number. Sending the scaled up [phasor~] output to this results in a ramp that is synced to the subdivision. This is then subtracted by .5 to scale the range from -.5 to .5, just so there are some zero-crossings.

[zerox~] is used to detect the zero-crossings. It doesn't seem to have a helpfile, and I'm not sure what the difference between the to outputs are. I just know they very briefly spit out a 1 when crossing zero. [edge~] detects sudden jumps in a signal and outputs a bang, which is used to drive the counter.

It's just occured to me that [zerox~] detects zero-crossings going up and down, and I designed the patch with the idea that it should only detect signals crossing downward. So it's actually going twice as fast as it should! Dividing the bpm by 120 instead of 60 should remedy that.

Hope that helps.

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()':

@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]

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