Here's the final version.

At first, it didn't seem to work -- the "old" and "new" [samphold~] objects were outputting the same value. Eventually I figured out that it was because I was trying to clean up the patch's appearance by passing the [phasor~] through a [send~] / [receive~] pair (going into the "old" [samphold~]). Apparently (which I didn't realize at first) this introduces a one-block delay -- so I was reading the "old" value too late.

Using direct signal connections for all of them, this does exactly what I want.

This is part of a multimode LFO abstraction that I'm giving to students. I'll go ahead and attach that -- -1 .. +1 range, LFO shapes are sine, triangle, sawtooth, pulse, random sample-hold and random with linear interpolation.

Thanks for the tips! Learned something.
hjh

lfo-norm-hjh~-help.pd
lfo-norm-hjh~.pd

this one does the same for list elements: text-element-fifo-lifo.zip if there are only numbers in the list an array could be more efficent, because it is possible to resize the array instead of copying the list.
edit: perhaps this is a simpler solution for list elements, and it looks almost like the abstraction [list-drip-slow] from list-abs element-fifo-lifo.zip

@emens ; https://github.com/porres/Live-Electronic-Music-Tutorial/releases

"Live Electronic Music Tutorial with examples in Pure Data and the ELSE Library By Alexandre Torres Porres

This tutorial presents theory and practice of Live Electronics topics without any prerequisite. It's aimed at newbies, dummies, enthusiasts and also experts. Pure Data is adopted in the examples for its accessibility and for being a powerful didactic tool. Nonetheless, this work relies heavily in the ELSE library for Pure Data, also developed by Alexandre Torres Porres, the author of this tutorial => check about the ELSE library here: https://github.com/porres/pd-else"

ctlout sends data twice before updating data sent to it

[127] [3] [4]

[ctlout]

[print]

results are value 127 cc 3 channel 4

Then I change data to

[127] [6] [3]
[ctlout]
[print]

results are value 127 cc 3 channel 4
but when I send the data stream again then ctlout send correct data
value 127 cc6 channel3

basically once I send the first data stream to ctlout in order for ctlout to send the currect data I have to press the buttons 2 times

Hi All
A little bit of work to set up but forget midi mapping...google it if you dont believe me.
After a lot of time spent trying to get a simple but sophisticated way (using a minimal 8 button floorboard) to control Live on w10, I thought I would share this particular solution to possibly help others (especially after the help offered here on this forum). I tried a number of scenarios, even buying Max 4 Live, but it turns out a lot simpler than that. It needs 3 main areas set

FOOT CONTROLLER BEHAVIOURS/GESTURES
Create pd patch that gives you 'behaviours' per switch. Ill be happy to share mine but Im just cleaning them up atm.
eg I have 4 standard behaviours that dont take too much time to master

1. Action A: A quick click (less than 500ms) Always the primary action
2. Action B: Long click ie 1 click down and pedal up after 500ms. I use this eg always as a negative ramp down for things like lowering volume but if its just held down and released in a natural way, it is the secondary action of the switch
3. Action C: 3 Click ie 1 quick down, up and then hold down. I use this for a positive ramp eg as volume up
   4 Actiion D: Double click, Always a cancel
   These are all mapped to note/ctrl outs that match the 'Selected Track Control' below

PLUGIN
Use PD VST to create a plugin version of your patch. This is loaded into Live as a control track. Live manages the connection of your floor board etc into the actual track so you dont wrestle with the io. I always use track 1 for click (forget Live metronome, this is much more flexible and can have feel/swing etc) so I dedicate track 2 to control.
Use LoopMIDI to create a virtual midi cable that will go from this track and be fed into the remote script.

REMOTE SCRIPT: 'Selected Track Control'
Download latest from http://stc.wiffbi.com/
Install to live and make sure your notes/control conform.
Enable this as a control surface in live and connect midi in from the plugin. Think about giving the guy a donation...massive amount of work and he deserves it!

I use it to control 8 tracks x 8 scenes and is controlled by 3 switches

1. Scene control up and down (A = down, B = up)
2. Track control same as scene
3. Rec/Fire/Undo Volume up and down (A = fire/rec, B = Volume Down, C = Volume Up, D (Dbl Click) = Undo

The scenes and tracks wrap so there isnt too much foot tapping

There is quite a bit more to it of course...its and maybe no one else needs this but it would have saved me a couple of weeks of time so Im happy to help anyone wanting to achieve gigging without a massive floor rig and an easy way to map and remember.

HTH someone

Cheers
mark

@Jocketor I mean that it can be done very fast as an analysis once you have all the data in an array..... so if you load an audio file into an array... or you have written a live input to an array..... then the analysis will be much quicker than doing it "live" in the audio domain where you are waiting all the time for audio blocks to complete their processing.
Do you want to show the user the results "live" while they are recording the audio..... is that why you want to use audio objects for analysis?
If you want amplitude values during a "live" [adc~] recording you can use [env~] to output those values (although in dB) at the end of each audio block (or set a wider..... or a narrower window if you wish for [env~]...... right down to a single sample if you set the block size to 1).
David.

I'm fairly new to Pure Data, though I'm excited by what I've learned so far. I followed this tutorial -- http://designingsound.org/2013/04/pure-data-wavetable-synth-part-1/ -- up through the second-to-last step (with some adjustments for things that didn't quite work when I followed them in the tutorial), and then began modifying it to add more modulation and other features I wanted. I'm currently trying to implement what I'm thinking of as "suboscillators" that will be able to be tuned in relation to the main oscillator, mixed in with it, modulate pitch and amplitude, and take their own envelopes. I also want the suboscillators to be able to take modulation from either of the two "LFO"s [in quotes since the first LFO actually outputs in the audible range] (adding a second to what's specified in the tutorial, along with additional layers of LFOs below them), so I've been moving things around and redesigning the patch a little bit, breaking it off and on, and trying to get it working again.

While working on this, I noticed a behavior that's baffling me: the signal of the first LFO appears to distort when sent out through send~ and then back in through receive~. If I connect the output of the LFO directly to dac~, it sounds fine. Sent through send~ and back through receive~ and then to dac~ and it sounds louder and there are some other frequencies seemingly present, as if it's maybe clipping a little bit. I thought that send~ and receive~ were functionally the same as just using connector cords, so I'm seriously confused by this. For the purposes of the patch, having the LFO signal distort is not good, so I feel like I need to figure this out before I go forward with the features I want to implement. Being new, I imagine it's something simple I'm overlooking.

Here's a link to part of the patch where the problem is occurring: http://imgur.com/a/GkRUI I haven't tested yet to figure out if other send~ receive~ pairs are causing distortion. Any clarification or ideas about why this is happening would be much appreciated.

[edit: There's also apparently an error message going along with this: "consistency check failed: signal_free 3" I thought it was some other part of the larger patch generating the error, but I copied just the LFO generator section to a separate patch to play with, and that message still appears in the console. The weird distortion with receive~ still occurs too.]

Using one oscillator to control the pitch of another achieves basic LFO. Of course you can use more complex waveforms for either the LFO or the signal, but the principle remains the same.

Hi,

I am not sure if your question is about this specific example of about format specifiers in general. In case it's the latter, then Pd uses the same format specifiers as the C programming language, see: https://www.le.ac.uk/users/rjm1/cotter/page_30.htm

%lf is used for double precision floats if I am not mistaken. So basically if you ask a C program to print the string (%lf:%lf)(%lf:%lf)(%lf) and give it 5 double precision floats as arguments (let's say 1.0, 2.0, 3.0, 4.0 and 5.0 for our example), the program would output (1.0:2.0)(3.0:4.0)(5.0).

Cheers,
Gilberto

Hi,

Is there any help patch or documentation about the (%lf:%lf)(%lf:%lf)(%lf) syntax used in variables for template fields?