I got a response from the creator of Gridflow on the mailing list, which I'll reprint here in case it can help people

I've made a simple video mixer in Gridflow (9.13) and I want to send the output to an external projector. I've set up my computer so that I can drag windows to the second screen, but when I attempt to go full screen using [#out sdl] and then pressing Esc it goes fullscreen on both screens.

Sounds like the kind of problem that can't be solved in GridFlow. It's a SDL issue.

If I use an [#out window] object, which I believe is an x11 window, there's no way (that I can find) to go full screen, so I'm stuck at with an 800x600 window on a 1366x768 screen. I did attempt to use a [#scale_to (768 1366)] object to emulate being full screen but the scaling causes a massive drop in framerate.

Changing the screen resolution is a sure way to avoid even having to scale.

[#scale_to] is a simple abstraction not meant to be fast or fancy. It would be a good thing to make a much better software scaler for GridFlow (interpolating and faster), but it wouldn't be as fast as a hardware-accelerated scaler, or simply changing the screen resolution.

Changing screen resolution also gives you the best image quality when using a CRT, whereas on a LCD it just means you're getting the LCD monitor to do the scaling for you.

Can anyone suggest how to go fullscreen on only one screen, how to go fullscreen using an x11 window or some other way to do this?

There is the "border" method for removing the border, the "move" method to put a window wherever you want (compute window coordinates to match the way the mouse travels from one screen to the other).

A fantastically helpful reply. I had been making a patch that manufactures sequencer grids, which I might finish, though it's more of a cool idea than a practical necessity. While I was making it I did have many many thoughts about what would be cool, and I came up with a really big one, which I will share when I've finished a version of it. It presents one solution to the randomness/inhumanity problem.

Yeah I was considering using color changes with the toggles. I am pondering allowing for color-based velocity for each note, or maybe using an "accent" system that loudens accented notes by a certain modifiable percentage. I was also considering using structures to make a sequencer, but I don't want it to be really processor heavy. I might also purchase Max at some point to get another perspective on this live machine I'm building.

I do like the idea of weighting different sounds, timewise, maybe having some sort of changeable lead/delay param for each sequencer lane. Of course I am making pretty straightforward beat music, so anything weighted too heavily will have to be for texture and color rather than the core of the beat itself. I am also curious about the different ways to shuffle sequences, as with the MPC having a particularly pleasing shuffle algorithm. I guess I'm interested in rhythmic algorithms.

Anyway, I'm gonna just build as many different kinds of sequencers as I can think of, put them in a big patch, then have a MIDI router that allows me to output the sequences as note, CC, or other types of messages, then control various Pd and Logic synths from there. My true mission is to design a performance instrument that allows for tons of flexibility (independent sequence lengths, or being able to switch the output of a given sequence element), and with a very special twist. I can barely contain myself.

I think the ability to output any kind of message is one of the true strengths of Pd when compared with Logic. If I want to generate movement with a synth's params, I have to use that synth's internal mod matrix (if it has one), or I have to use automation which exists in a GUI element separated from any note information. I don't want to go digging into the nested windows of my sequencer program to be able to quickly program automation.

This conversation has me really excited. Thanks for the valuable input. And who are you, by the way?

D

i find, one of the good things to do, is to play round with a normal sequencer, and when you get a thought like "oh man, i wish i could just turn off the second half of the sequence every now and then", write that down, and then include that function in your own sequencer.

also, if you're designing a sequencer using pd's gui, those toggle buttons are absolute crap. but you can make them better with a bit of tweaking. instead of having just the little X show up in the middle of the toggle box, send a message like this:

[r $0-toggle-1(
|

• <- whatever number you put in here, is the colour
  |
  [color $1 $1 $1(
  |

that way, the whole box gets turned on and off with a click. makes it much easier to see what's happening.

also, one of the biggest strengths with sequencing in pd is the ability to randomise, either randomly or intelligently. for example, if you are making a random drum pattern, then you probably want more notes to fall on 0,4,8, 12 than on 5, 7, 11....etc , so you build a patch that does that with weighted randoms and then you get reasonably cool sequences right off the bat that can be tweaked manually to work well.

just thinking of your idea about 'colouring' sequencers so that they lead or delay notes, and i think a cool way to do that would be to actually colour the individual sounds. so, for example, with a typical bass drum and hihat thing, you probably want the bass drum to be pretty steady, so you could assign it a colouration factor of 0.2 or something. but the hihat should be allowed to roam a bit, so maybe give it a 0.4.

but yeah, i think one of the best things about pd, is that you can program in all sorts of bends and tweaks that regular sequencers don't have. especially randomising stuff, makes it easy to try a heap of sequences very quickly. only problem i find with this type of method, is that it does tend to lead to the sounds becomign very erratic very quickly. with traditional sequencers, it takes a while to get all the notes in there, and you're more likely to just let it loop for a while and keep the same groove. but once you start getting into highspeed loop prototypes with randomization, you can switch between heaps of different sounds really quickly. this is really cool and definitely has advantages, but on the other hand, music is also something which has to come from the soul, so the jitterbug randomness does often mess things up too much. it's a bit of a balancing act, maybe. but if you can program the randomising stuff to work well and generally hit on good results, then that is better.

not sure if i answered much of the original question, but good to have a think about these things. cheers

I like Logic for many reasons. Sometimes I like that the sequencer is totally regular and orderly and normal. Sometimes I don't. I can do all kinds of awesome things with sequencers in Pd, like making sequencer patches with individual lanes that run at independent rates, for example. So I'm setting out to design a big improvisatory sequencer patch that includes drums, synths, samples, and loop-based recording. It will be totally awesome.

So designing sequencers and using vintage drum machine samples has got me thinking. I've read a handful of interviews with hiphop and techno producers who swear by hardware sequencers and drumboxes. They particularly tend to talk about the "feel" of particular sequencer or drumbox. I get that I won't really be able to replicate the metal frame of a LinnDrum in Pd, that there's something about the buttons, the knobs, the hardware-ness of these machines that encourages a certain style of composition unique to each box.

Given that I'm accepting certain limitations in GUI with any sequencer I design in Pd, how can I effectively create a sequencer that has a unique feel? And then, how can I create another one, with another unique feel? And on and on.

I also understand that certain sequencers, apart from the compositional elements of their front panels, also "color" their rhythmic outputs by leading or delaying the notes in a pleasing manner. Are there schematics somewhere that indicate how this occurs, per individual sequencer?

Also, an appeal to y'all imaginations. Who has cool ideas for sequencers? How can we flavor our sequencers uniquely so they aren't just spitting out Logic-esque, highly regulated streams of notes?

You guys are awesome!

D

PS - Best believe I am working on weirding up Logic's sequencer from within!

I'm not so sure about getting the coordinates of the touch points. Why do you want the coordinates? What's your OS?

The only thing I can tell you is that a single touch device is interpreted by the OS as a mouse...and that's hella useful. I don't know anything about multi-touch. Perhaps the OS is okay with simply interpreting it as "two mice." I think the problem is a question of it knowing that these are two distinct events - it needs extra info about one point being held down as the "other" is active. I just performed a test on my single-touch device - if I hold down one point on the screen and then tap another it will jump to the new point and stay there until it detects movement someplace else (as with a synaptics laptop touchpad). That said, as far as the computer is concerned, it registered both points, so if you really do only need the raw data, you might be able to get by with a single-touch. Say, you have different active spaces on the screen - like 4 Grid objects, one in each corner. You could touch them practically simultaneously and you would have 4 distinct coordinate outputs - with a single-touch device. You would run into a problem if you wanted both inputs to move simultaneously and you need continuous output, even then you may be able to come up with some kind of interpolation.

You can see my recent giddy post about my single-touch device using the Grid object - I hope that Acer has all of the drivers and lists compatibility online.

If you don't need multi-touch get an Elo, they are really cheap! As a matter of fact, you could probably get two or three Elo's for the same price, and THEN you have multi-touch.

• J.P.

Hi all,

I feel that this is now at the point where i can start showing it to people and possibly getting some feedback. This is based off a Midi sequencer i wrote for the NDS but is now aimed at my touchscreen tablet which has a much bigger area to play with.

everything can be downloaded from my github repository

http://github.com/notesandvolts/Touch-Sequencer

The sequencer has two parts :-

Pure Data sequencer does all of the data stuff, midi sequencing, value storing.
The Python GUI just makes everything easier to use and a bit prettier than stock PD. It uses pygame for all the graphical stuff so you will need this to be installed as well.
The two communicate over OSC and my eventual plan is to have the tablet communicate with a rackmounted server over a wireless netwwork.

Features
2 channel types, Grid and Curve. Grid features 8 grid based patterns either 8 * 16 or 16 * 32 sized grids. The patterns themselves are sequencable and there is a follow mode that shows the patterns being played on a channel so you can more easily edit it on the fly.
The curve channel features 8 wavetable LFOs with user drawable waveforms, variable lengths and independant midi channel capabilities. They currently only do standard Midi CCs and no pitch bend but thats something I want to change soon.

The sequencer sends out Midi clock start/stop/clock information so it can be used as a master clock for a bunch of gear. It currently doesn't sync to a midi clock but again i'd like to do that eventually.

I've tested the whole thing a bit and it works however i'm sure there are going to be more issues. Any feedback is welcome, even if its people just giving advice on how to do something better. The user interface is currently ugly but then i'm an engineer not a graphical designer

I hope people find this useful or informative or hopefully both.

Thanks for taking a look

Guy

the sequencer's cool but it's a pain to label since it's so squished. the bottom left numbers just show what steps you're viewing, since you can only view 16 steps at a time, and you select which 16 steps you're viewing with the thin, long hradio in the middle. click around that and you'll see which sets of steps you're editing (1-16, 17-32, 33-48, etc.) up to 256 steps total. in the middle bottom, that number is where you set how many steps you want - it defaults to 16. the bottom right is the tempo, and the box next to that is just a counter to show what step you're on when playing. the small size 4 hradio to the right isn't currently used, but that's there so you can switch between 3 other sequences in the same sequencer.

i really didn't clean that patch up enough - i just realized two of the inlets set the total number of steps... the leftmost inlet sets the bpms and the rightmost is a toggle for start/stop. also sometimes when you save a sequence that's last value is a nonzero, if you extend the sequence after that it'll fill the new steps in with that value instead of zeros.

ultimately it's pretty multipurpose, what i usually do is run the outlet into a [select 0] just to throw out the 0's (since maybe you want to sequence negative values sometimes). the explanation in the patch just tells how it works with that specific sampler - to sequence it it takes 0-7 to trigger the 8 different lookup points, and it wraps so you can send 8 as 0, 9 as 1, etc (i like to do it like that so i can still throw out the zero's and not have to scale the input over a value in the sampler).

i forget who it was but someone in #dataflow inspired this sequencer - i had started with a small 16 step sequecner, then just made it bigger until it was a huge 128 number box GUI lagfest... discussing ways around it someone suggested that you use a sort of switching system so you can only VIEW 16 steps at a time, but can shuffle around a larger sequence. ultimately it took a while to figure out how to set up but it was super rewarding, the thing is super handy and has save/load! buyakasha!

> yes, probably. but now I'll try to run it on my Atari ST

Seriously try it if you get time one day. Oddly the Atari ST is still *THE* choice for some serious techno musicians. Why? The simplicity of how the UART is addressed and clocked gives it rock solid midi timing. It's something that seems to elude complex architectures even with the best preemptive scheduling, buffering etc. I've watched top producers take a midi file on floppy disk from their $5000 super Mac/PC systems to have it play back on an Atari for final mixdown. It's one of those analog vs digital type debacles where real experience of good ears trumps what "technically shouldn't be so". The ST lacks enough grunt for useful audio DSP, but as a midi processing hub or sequencer it could be an astonishingly powerful tool with pd if you can compile it.

>mhh... this is just a anthropomorphic vision of reality...

You got me.

>what I need to ask now is where I can find reference for all objects:
>I know that there's no menu of them and i have to type their name in those little boxes, but
>I need to know, at least, what objects I can create, typing their names, is it true?

Yeah that bothers me too. Even after using for it some time I forget the name of an atom and have to go looking for it. I often do something like "ls /usr/lib/pd/externs/ | grep pd_linux$ | less" to see if I actually have something. For windows likewise search the externals directory for .dll files

>so, I would like to have a list with the object identifier (for oscs, filters etc.), their
>details (kind of filters, slopes, ripples etc. for filters, as example ), their parameters (cutoff, Q, etc.)
>is there a documentation like this?

The help files are detailed, well written and easy to use. Once you know that such an object exists. Just right click any atom and select "help". Usually there's an example case.

Check these to find common atoms
http://puredata.hurleur.com/sujet-248-suggestions-noobs
http://ccrma.stanford.edu/courses/154/pd-reference.html
http://pure-data.sourceforge.net/documentation.php

>I know... but I still feel more confortable with a traditional language (C++, pascal), also
>for writing my personal VSTs (you know, for those weirdest things...) I think it's still easier to write "algorithms" with a textual language,
>without a graphical metaphore.

Raw code is not an expedient or practical way to make music. Having used Music(N), Csound, Nyquist (LISP/SCHEME), and all that stuff I can say this from the bottom of my heart after 15 years experience. Pd gives you two really important things from a software engineering point of view. It's modularity and clarity of interface in abstracting things just beats any C++ classes hands down for it's intended purpose - digital signal dataflows. Consequently you get better decoupling and better reuse. One of the few pitfalls for a trad programmer imho is that pd is very dirty on types, in a way it's one of the most badly typed languages I've ever experienced. Ironic for a tool called "pure data", but you get used to it's lovable idiosynchrocies vis lists, messages, numbers, arrays, symbols and generic "anys". Also it's scoping rules leave a lot to be desired, everythings global within one instance of the server unless you say $0- at the head of a name.

>But now I need to teach a course on "languages for electronic music" in classical, academic shool.
>they don't know DSP matchematics or something like,
>so I need to urgently search for use a more "abstract" instrument for doing the lessons...

You couldn't wish for a more appropriate tool. For non maths/physics students you can use the power of abstraction to build "black boxes" like synths, analysis tools and sequencers and then open them up later in the course. As Claude says, it takes about 9 months or more before you really take to PureData. Electronic music is BIG, really big, not as big as space but it's a discipline that just explodes in scope once you get into it. You can waste weeks writing externals in C, or designing a synth, or creating a composition method...you can get really lost on a random walk in d>2. The best way forward is to have a context and a goal. Teaching this course sounds like an excellent vehicle to focus your scope.

>Tried also Jmax but on Windows (required OS, because > 95% students use billgatesware ) is quite unstable

I would make it "unrequired". Put your foot down as course leader/tutor that Windows is unsuitable. In order of preference I would go with Mac, then Linux, then Win. If the students only have Windows then try Dyne:bolic ( http://dynebolic.org/ ), a minimal GNU/Linux distro that runs from a CD in RAM and comes preconfigured with PureData and a smorgasboard of other digital media tools. That said, I've seen it work really well on Windows. Once. I've no hard evidence to back this up, but I feel a disturbance in the force when Pd runs on Windows, as if a million threads cried out at once and were suddenly silenced. I don't think it likes heavily loaded machines and I guess 99% certain the reason it's unstable on Win is down to *other* things running. Hint: a music machine shouldn't double as an email server and GCHQ spyware centre. Start with a clean install and nothing else running and you may have better luck, but that will probably remain stable about as long as a schizophrenic Z-boson particle if you network it.

hi all.
this is my first post in this nice forum which i recently discovered. i'd like to say hello in form of offering a track i just finished some minutes ago using my bagoftricks abstraction collection:

[url=https://www.puredata.org/Members/syntax_the_nerd/pleasehurt ]https://www.puredata.org/Members/syntax_the_nerd/pleasehurt

i know it's not really good, but maybe thats due to the fact i don't even like electro, nor listen to it usually. the drums are boring, the melodies dull, and please don't mention the bassline, but anyway, all is done in pd within about 2-3 hrs, even the sequencing (semi-live, like scheduling step-sequenced loops with keyboard commands). no samples in this one, just pure synthesis. comments welcome.

if you're interested, feel free to peek into my bagoftricks abstraction collection, offering a very compact pseudo-modular synth, a shabby physmod guitar synth, 2 1/2 drumsynths, a modular sequencer which is a pain in the ass to use, a whole bag of standard effects (from reverb to pixelator, eq to compressor),pseudo-cpu-management, some example loops, eyecandy sliders, and best of all: a (highly unfinished) tutorial. needs iemlib. no samplers here, no OSC, no nothing. just an attempt to rob all the artistic freedom from pd and push it into step-sequence sized quanta. depending on what you plan to do with it, it will need a decent cpu.

[url=https://www.puredata.org/Members/syntax_the_nerd ]https://www.puredata.org/Members/syntax_the_nerd

the track you might have downloaded earlier will be included in patch form in the next release (0.2.7) of the bagoftricks.

thank you for your patience,
stn

I made an event looper "eveloop" patch with [textfile], works like a tape loop, storing and playing back any Pd messages in a loop. The patch is complex and has a few bugs still, but it works enough for me to make interesting sounds.

Screenshot of patch that does the work (a bug in Pd ate the name labels on the canvases):
[url=http://puredata.info/Members/claudiusmaximus/copyme/gravity/screenshots/gravity-20040622-cm_g_eveloop.pd.png ]http://puredata.info/Members/claudiusmaximus/copyme/gravity/screenshot s/gravity-20040622-cm_g_eveloop.pd.png

Screenshot of patch in use:
[url=http://puredata.info/Members/claudiusmaximus/copyme/gravity/screenshots/gravity-20040622-cm_g_gravity.pd.png/ ]http://puredata.info/Members/claudiusmaximus/copyme/gravity/screenshot s/gravity-20040622-cm_g_gravity.pd.png/

Patches cm_g_eveloop*.pd are part of Copy Me - Gravity, they require IEMLIB for [prepend] and [gate]. The cm_g_gravity.pd patch also requires my DCM100 Mixtab patches, but the rest don't.
[url=http://puredata.info/Members/claudiusmaximus/copyme/gravity/source/ ]http://puredata.info/Members/claudiusmaximus/copyme/gravity/source/

Some sounds made with it - the ones after 2004-06-20 use eveloop, earlier ones just had a [metro]:
[url=http://puredata.info/Members/claudiusmaximus/copyme/gravity/sounds/ ]http://puredata.info/Members/claudiusmaximus/copyme/gravity/sounds/

Todo for the future: make a bank of 16 loops in parallel with a unified GUI, to make it easier to make music - it is hard when one loop contains all the control data for an instrument, you can't change just one controller without clearing all the others. I have a good idea how to do this, and I have time too, but I am lazy