Assumptions:
The drum kit generates MIDI data.
You want to play sounds by MIDI from an external sampler/drum-box
You want to learn more about Pd and not have someone hand you your project on a plate

1. Decode the midi - you need to create a [midiin] object and use [select] and [route] to catch the events when the pedal is pressed.

2. Create a step sequencer that inserts events in a cyclic buffer/storage system (in overwrite mode) *hard part

3. Use a toggle to switch the recording on and off with alternate pedal events.

4. Connect output of the step sequencer to a [midiout] object or to some drum synthesisers you make in Pd.

5. Add a metronome bleep so you can keep time.

6. Pick up your drum sticks...

(Note - you haven't thought about (or told us about) some still unsolved problems. A sequencer capable of making polyrythmns needs more than one concurrently running sequence, same timebase but unrelated bar lengths. Work on that first because it defines an important software engineeing decision which effects how your sequencer must work (hint: is it track based or layer based or something else? That effects how you delete events (unless you plan on playing everything right first time))

Hi,

In Gem librarie, you can add an alpha channel to every streams you want to "dissolve" using the object [alpha] just after the [gemhead] and with [colorRGB], the fifth inlet is for alpha value, at the outlet, you can add the necessary objects for displaying videostream on a geo (square, cube, cuboid, ect...) with using [pix_texture]. with using a [separator] object at the outlet of [alpha], you won't have the need for using other [gemhead] for the other videostreams (other layers).

Indeed, the original midi specs give separate headers for noteon and noteoff messages being 0x80, K, V, - Note Off and 0x90, K, V Note On, where K and V are 7 bit key and velocity values, or 1001xxxx and 1000xxxx for the headers as they actualy appear on the UART (physical layer) with the nybble xxxx being the channel.

Problem - about 1987/88 a widespread assumption started to be that noteoff K=x V=0 could replace the authentic noteoff for Key x, so a lot of hardware manufacturers started using this too.

Totally stupid!!! (which is another reason why midi is the bastard spawn of Beelzebub)

Grepping for noteoff in x_midi.c I don't see any handler for an authentic noteoff header, which makes noteoff velocity impossible in Pd unless you want to add it to the source and recompile.

Solution - trap the noteoff velocity somewhere else before Pd and convert it to a controller message. Sorry, that's the best I can suggest right now.

i think one thing you should take into account when designing a GUI is something that will fit well ontop of the work you've already done. if your patch has a message handling structure already embedded in it (one that is sufficient to control all parameters of your patch), it would be very easy to employ either of the trends mentioned above.

if your patch has a set up where many sub-patches on a main canvas, perhaps the graph-on-parent method would work well.

another consideration is displaying information from your patch (not just controlling or changing it).

though i guess the main thing is usability. certain components and controls are going to fit your patch better than others. if your patch needs to be used in some type of performance, what features will make the patch easiest to use for the performer.

i do not know much about it other than it exists, but joseph sarlo at UCSD is working on GrlPd...sometype of layer for making GUI's for your patches. the link is [url=http://crca.ucsd.edu/~jsarlo/gripd/ ]http://crca.ucsd.edu/~jsarlo/gripd/

i hope this helped some and perhaps it will stimulate some forum discussion.

arrrrrgggg:

This is the GridFlow 0.8.0 configurator within Ruby version 1.8.2
[fast] Compile for speed (and not debuggability): enabled
[gcc3] GNU C++ Compiler 3: missing (undefined method `<' for nil:NilClass)
[stl] C++ Standard Template Library: missing (gcc compilation error)
[gcc64] GNU C++ in 64-bit mode: missing (gcc compilation error)
[libruby] Ruby as a dynamic library: missing (gcc compilation error)
[librubystatic] Ruby as a static library: missing (gcc compilation error)
[pentium] Pentium-compatible CPU: missing (gcc compilation error)
[mmx] MMX-compatible CPU (using NASM): disabled (would need pentium)
[simd] SIMD (MMX/SSE/Altivec) (using GCC): disabled (would need pentium)
[profiler] profiler (speed measurements): disabled (would need pentium)
[usb] USB Library: missing (where is usb.h ?)
[ieee1394] IEEE1394 Libraries for Linux (raw1394/dc1394): disabled (by author)
[x11] X11 Display Protocol: missing (where is X11/Xlib.h ?)
[x11_shm] X11 acceleration through shared memory: disabled (would need x11)
[sdl] Simple Directmedia Layer (experimental support): missing (where is SDL/SDL.h ?)
[objcpp] GNU/Apple ObjectiveC++ Compiler: missing (where is objc/Object.h ?)
[quartz] Apple Quartz/Cocoa Display: disabled (would need objcpp)
[aalib] Ascii Art Library: missing (where is aalib.h ?)
[jpeg] JPEG Library: missing (where is jpeglib.h ?)
[png] PNG Library <libpng12/png.h>: missing (where is libpng12/png.h ?)
[png] PNG Library <png.h>: missing (where is png.h ?)
[videodev] Video4linux Digitizer Driver Interface: missing (gcc compilation error)
[mpeg3] HeroineWarrior LibMPEG3 <libmpeg3/libmpeg3.h>: missing (where is libmpeg3/libmpeg3.h ?)
[mpeg3] HeroineWarrior LibMPEG3 <libmpeg3.h>: missing (where is libmpeg3.h ?)
[quicktimeapple] Apple's QuickTime: missing (gcc compilation error)
[quicktimehw] HeroineWarrior QuickTime4Linux (or LibQuickTime) (try #1): missing (gcc compilation error)
[quicktimehw] HeroineWarrior QuickTime4Linux (or LibQuickTime) (try #2): missing (gcc compilation error)
[xine] Xine movie decoder: disabled (by author)
[puredata] Miller Puckette's Pure Data: disabled (would need libruby or librubystatic)
generating ./config.make
generating config.h
creating Makefile

humm.... it will probably compile but seem will could do not much without jpeg png video4linux X11 etc....

will wait a .deb package...

the bits that won't copy are abstractions. they are links to other patches saved in the same folder as the parent patch. if you don't know the difference between abstractions and subpatches, then you're gonna need to learn that...and it takes a little while to understand.

but, anyway

there are two ways you can copy these bits:

1. if you are working on a patch, then you need to save the "output.pd" abstraction in the same folder as the patch you are working on. you can then make [output] work just like a normal object.
2. open the offending [output] layer in it's original help file, and copy the contents to your clipboard. then, in your blank project, make an subpatch called [pd output] copy your clipboard contents into that.

hi guys, as you can see from my previous message i am pretty new to this program so pls excuse my basic questions. the way i am going about learning is by copying and pasting examples from the help files to a blank new 'project'. this seems to work some of the time but sometimes it doesn't eg. when i try and copy an object that has a number of layers or contains another set of objects. this happens when i try and copy an output object from the help files, not all of the output copies and it doesnt work. if anyone could help me out with this or let me know howw to copy examples that have a number of 'layers' then i would be really grateful.
thanks in advance for any help.
cheers
ali

tjeerd - are you still trying to make pd externs? i couldn't figure out how to do it with straight C code, but i was able to successfully compile, link, and use externs using flext. flext is a C++ layer for making objects for both Pd and Max/MSP on different platforms. seems pretty easy to setup and use. i don't know the flext website offhand, but just google it and it comes up. oh, one note about compiling flext--unless you alter some of the compiler definitions, you will need the 'processor pack' (which requires msvc++ service pack 4 or 5). hope this helps.