Hi,

while using Herrmutt Lobby's beatfader patch (

), I felt like the cheap controller I were using had a rather limitated refresh rate (time resolution). This caused 'missed' samples triggerings.

This decided me to write a patch to TRY to retrieve directly this info from a played controller : simply connect it, play it and read a value.

I tested it with a stable midi LFO with different time resolutions, and the results are rather satisfactory.

This leads me to the idea that if this patch works, anyone anywhere on earth can pick up his own controller and make the test, and then share the results with the community. This retrieved information is nearly never given by constructors, and I would like this humble patch to become a friendly tool allowing us to compare devices on this criterion.

What do you think of it ?

How to use it :

* First bang the 'timebase'
* then move ONE controller at a time (no surface pads), rather rapidly till you find the higher 'stable enough' value given by the homebrew rate

Enjoy !

It's stupid by I couldn't test it under Pd because I don't have a controller here with me, but it has been ported to Max For Live and gives values around 60-70 hz with the hercules dj control mp3

Tell me,

Nau from Herrmutt Lobby

http://www.pdpatchrepo.info/hurleur/controller_timerate_retriever.pd

hi guys! so i've had an oxygen8 for a few years now and i see them everywhere, so i'm sharing this handy little patch i made.

basically you're stuck with 8 knobs, and two sliders (modwheel and data entry). all this patch really does is takes the keyboard's input, numbers those 8 knobs and 2 sliders in sets of 10, and lets you switch between those sets with the hradio for up to 120 different controller values. the key input is passed straight through so even when you switch between various controls you can play the keyboard consistently.

even if you don't have an oxygen8, this patch will give you a little selfcontained set of sliders that you can use as a midi controller... so it's still useful for when you're not at home with your keyboard, or if you don't even have one.

basically all this patch does is take those 10 controls and lets you switch between 12 sets of them. it's useful for me in ableton so when i need to map more parameters than i have knobs for, i can assign more, and the numbering system is much easier to stay on top of than the default control values for those knobs (it's like 17, 80, 74, no consistency it seems).

on linux you should be able to jack the keyboard to pd's midi in, then jack the output to wherever you want. i'm currently on windows and i select usb keyboard in for input, and loopbe for output.

the numbers do nothing but change when you switch the hradio - the sliders are the corresponding controls (with the mod wheel as slider 9 and the data entry knob as slider 10).

come to think of it i don't think i tested the pitch bend wheel, i've been using this patch almost entirely for parameter controlling and not playing the oxygen8 notes at all. [notein] is patched directly into [noteout]

any questions/comments/ideas please, post them. this is a real quick patch i put together that worked almost better than i wanted it to but it can be very expanded upon. i was going to add symbols so you could tag/name all 120 controls but i was having trouble figuring out a way to store them and recall them, and send/receive to the symbols... so i just scrapped that.

basically all i do is make a tiny pd window and make [SCET], and just have that sitting at the bottom of the screen under my DAW (in this case ableton).

i haven't run into any conflicts yet for the most part but it's possible the controller numbering system might conflict with certain apps/synths/etc.

cheers guys!

http://www.pdpatchrepo.info/hurleur/SCET.pd

i'm not shure this is your case because it seems you're using a midi software synth and a sensor but i know that "if you hear double notes when playing your MIDI keyboard, (slapback echo or flanging, the chances are that MIDI Thru in your sequencer and Local Control on your keyboard are not set up correctly. This causes the keyboard to sound two notes - the one you play on the keyboard and another being echoed from the computer...
On your keyboard you need to switch Local Control to Off. This disconnects the keys from the sound circuitry so sounds can only be played via messages arriving at its MIDI In" (http://www.practicalpc.co.uk/computing/sound/miditop5.htm)

but i'm not so shure this helps... what midi module are you using? is it hadware or software stuff? you can try to monitor icoming midi messages with midiox to check that everything is going right

HI. I made a little pd for changing in real time some midi data from a controller when you press a special key, like a SHIFT function. My problem is that I need to recall the shifted/unshifted controller position to resume the controller when it reaches again that position, like the "pick up" function in Ableton Live. The idea is to control more than one virtual controller with just one real controller.
I have it all working for just one real midi controller (I mean one knob or one slider sending midi controller values). I used "gate" and "sel" commands. I'm trying now to replicate the functionality with n real controllers.
In other words, now I'm just recalling one controller position value for any controller but not from which controller is that value. I need it to work multithreading, because the operator may wish to move multiple controllers shifted and unshifted, and every shifted/unshifted position must be stored somewhere for the pick up functionality.

Is this too much for PD? I think the algorithm in C and it's not that hard using hashmaps or something similar to store controllerID+controllerValue and check if it has a pick up value active.
Could you give me some directions using PD? Can I store and recall key+value in any way?

thanks,
Federico

This is my try at a no-sample drummachine. It's a rather complex machine, so i'll try to explain it as clear as i can, but still probably very unclear

To just make sound, you should (normally) do this :

• select a preset (bottom left)
• press the run button (top left)

Some more functions:

• there are four instruments (2 bassdrums, 1 snare, 1 hihat/cymbal thing), you can control their levels in the mix section
• each instrument follows one of the tables at the right (not the fifth one)
• to access each instrument's controls click the [pd controls] object. I won't explain each control, just try them. However, each instrument has a pink radio-strip, this selects which table the instrument currently uses. The brown radio skips notes.
• to ad grit, use the woodfire section (beware of your ears, although it will diminish the output level). This is my go at a constant-output-level thing (is this some form of compression?).
• there's a (vst) reverb section for which i normally use the free PSP pianoverb (its controls are mapped in the verb section parameters). The input to the plugin can follow the fifth table, by using the [folw] toggle. This might be a rather confusing section
• there's an FM section which can follow the snare and/or hihat (blue toggles in the mix section). The five sliders in the main section control the fm amount/depth/filter
• the green slider in the main section is the main level
• the organe [hp] slider is the main highpass-level

Something about the tables. Each table has a set of controls:

• Dark red clears the current pattern
• Dark blue randomizes the entire pattern
• Switch the green toggle on the record notes with the spacebar
• Light red button clears all notes except the recorded ones
• Light blue button randomizes all notes except the recorded ones
• The buttons marked < and > shift the pattern left/right
• The radiostrips selects an other pattern
• Patterns can be loaded/saved by the green/red buttons bellow the radio strip
• The very small green toggles enables/disables the auto-load-pattern function
• The randomization depth is controlled by the yellow slider bellow
• The orange slider / grey radio controls the number of steps played

Enjoy it.

Domien

http://www.pdpatchrepo.info/hurleur/CompDR.StandAlone.pd

@obiwannabe said:

A few remarks:

The pan control should really be one control that fades between the left and right channels, otherwsie the volume control is redundant if you have separate left and right fades. You might like to look at "equal power" panning. If you get stuck ask and I'll send you an example.

The volume control is so that I can fade each channel in and out.
But an example would be excellent.

@obiwannabe said:

Because you have 4 sources that are all potentially at full scale you should divide the total sum by 4.

Will do.
Also another thing, should I be keeping the [*~] between 0 and 1?

@obiwannabe said:

Maybe start using abstractions for the bits you duplicate instead of subpatches.

Yeah, I need to learn to do this, I should work my way through tutorials or something.

@obiwannabe said:

You could do quite a few things to build on the project from here. One would be to use the other joystick controls to add a bit of effects.

At some point you might want to make a "meta control" that can switch between channels you want to add some effect to.

At the moment the loops all run asynchonously (in their own time) That's cool, but for beat mixing you might like to try synchronising them all to the same pulse or having a speed control for each one so they behave like turntables and you can mix the beats.

All these sound like awesome ideas, I guess it's back to the drawing board to try work these out.
Infact, at uni we have access to these cv to midi converters and a whole load of awesome gadgets like distance sensors and bend sensors which would work nicely with tweaking effects.

I guess for the synchronising, I would need to resize the array to a certain length after loading in the sample then keep it in check with a [metro]?
A continuous resize might be a bit cpu intensive. I think I recall a patch that allowed you to slow down/reverse/change the boundaries of a sample while it played, being posted around here somewhere.

@obiwannabe said:

If you want to make life easy on your course masters and yourself may i suggest sticking to really simple Miller Vanilla Pd , don't use anything too fancy or you might find the difference between Pd and Max causes you headaches later on.

Ah yes, I realise now I'll need to include all the externals I've used, which to date seem to be [hid] and [spigot]

Infact, I'll just burn the entire current version on the disc I hand in with all the externals I'm using.

Thank you mr obiwannabe.

Hi All,

I've attached a patch that I constructed that converts a MIDI continuous controller stream of 1~127 into much higher resolution output (currently set to 127^2 steps). It basically ramps between one MIDI number to the next over a time period specified by the amount of time that has elapsed since the previous MIDI number was passed. Of course it still restricts you from stopping on a number in an range between two MIDI numbers, but at least it allows that range to be swept through.

For example, if you want to use a controller to sweep through frequencies from 20Hz-20,000Hz, if you use a MIDI controller normally it would pick out only 128 discrete frequencies over that range and step from one to another like stepping stones. But using this patch, if you move the controller from, say, 34 to 35, the result would be a smooth sweep through frequencies of about 5300Hz to 4470Hz over the time period equal to the time taken to change from 34 to 35.

Unfortunately, the major limitation is that the patch only knows the time period at the moment you reach the new number, so the ramp only starts by the time it should have finished. This makes it impractical to use for slow sweeps, but you could use a separate controller for these slower movements (one that is much lower geared).

Any suggestions for improving or expanding the patch would be welcomed.

I know that pitch bend already performs as a 14-bit controller, but I don't want to be limited to having only one hi-res at a time (I only have one pitch bend wheel!)

Cheers,
Brett

http://www.pdpatchrepo.info/hurleur/High_Resolution_Controller.pd

I like that track, kept me interested and made me smile, and when it finished I wanted to listen to it again - I've listened to it about 5 times this evening. Good work!

I've been trying to make similar sounds. I'm working on doing more live stuff with Pd, it's mighty fun, I can spend hours twiddling with midi knobs making freaky noises. I think I spend too much time fiddling with the knobs and not enough time enhancing my patches - I've not got much to show for the last six months of Pd-ing.

At first I was mapping each midi knob to a single control of the patch, but poorly thought out - in one patch I have 4 breakbeats, and I had 4 knobs mapped to the bpm control of each beat - "bpm 1", "bpm 2", "bpm 3", "bpm 4" - and it was a nightmare trying to get anything to sound good with it. Now I am trying to have more useful controls - "master bpm", "second pair/first pair bpm ratio", "pair 1 bpm spread", "pair 2 bpm spread". Still having 4 knobs to control the 4 bpms, but in a more musically useful way. Like a mathematical change of basis or change of coordinate system.

Another way I am trying to make live performance easier is using algorithmic processes - instead of controlling every beat I control aspects of a process that generates the beats - instead of being the drummer and the bassist and whatever else I am more of a conductor or director, controlling "jitteryness" or "density" or whatever. These processes can have a random part, so the live performance takes on a new element of reacting to the unpredictable output.