monome

thank you! i will check this out.

oh awesome. i was hoping to do this myself someday as an exercise in learning more about Pd. stoked someone did it; will definitely be going thru later today.

thanxs loads! been struggling recently with PD!

Thanks for this. It has motivated me to begin development of a full-blown mlr for pd. I have a rudimentary 8x8 working, with modular design for easy expansion for a 128 or 256, sequence record/playback, etc.

I have noticed that the technique presented in the tutorial produces a slight click when pressing a button and changing position in a sample. Any ideas on how to avoid this?

This is awesome!
I am motivated to learn now that I don't need to buy a copy of max to code.

bongo: I've also recently checked out this tutorial, and I also noticed a click. I think a way to avoid this would be to put an envelope on the signal. In mlrV it's the "microfade" option. Think about it as fading out of the previous position, and fading into the new position very quickly. If there is a discontinuity in the audio signal, then there is a click.

BoxieBrown: Thanks for the "cross fade" suggestion. I'll have to research the best way to implement this, as the patch currently uses a single sample reader ( in pd: tabread4~), driver by a saw tooth generator (phasor~) for positioning in the sample. his may require using two alternating sample readers with a cross fade between them.

Hello,

Thanks for the feedback.

Yup, this is a pretty bare-bones implementation, so you certainly will get clicks when cutting, if the sample values at your cut-points don't match each other (which I would say is more likely to happen than not).

I also think that micro-fades are the way to go, as BoxieBrown suggests. I'm pretty sure that you can still do this while using tabread4~ - on the output of the tabread4~, you can put a multiply block, with the other input being an envelope that normally is set to '1' (i.e. max gain), but will momentarily dip to 0 and back up whenever a button is pressed. This will momentarily mute the clipI believe this should do it. Hopefully that description makes sense. Come to think of it, it's the same thing that Boxie's suggesting.

ben

p.s. I should admit that I'm far from a Pd expert - this tutorial project was my first foray into Pd, so if there's anyone out there who is more Pd-savvy that wants to contribute to this discussion, it would be great to have them join in.

Ok, I looked over some of my Pd notes, and I think I have a more elegant solution to this problem. The idea is outlined here: http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.html

I'm attaching an abstraction of this method. Hopefully it makes some sense, and I think it sounds good. I also think it's a better solution than crossfading like in mlrV. Put this after the [tabread4~] and every time you press a button/slice, send a bang to the right inlet

Thank Mr. Puckette for this one, that's how I learned it, it's certainly not my idea.

I will try BoxieBrown's suggested method and report back...

that did not take long... i used the switch-ramp.pd patch and it worked like a charm - no audible clicks when a button is pressed.

Having such tutorial is really nice. Thx !

Before going for a full blown MLR clone in PD, consider axiome: http://docs.monome.org/doku.php?id=app:axiome . Axiome is a PD version of MLR. I never tried it myself but it seems pretty complete.

Jul

@BoxieBrown - looks good (and from Bongo's report, sounds good too).

@jul - thank you, I was remiss not to mention axiome in the tutorial intro. I did try axiome, but the audio was oddly mangled when I gave it a go. Possibly a setup issue on my end, admittedly. Anyway, I'll add a reference to it in the intro.

I chose MLR as an example simply because simioliolio's max tutorial on a one row version of MLR gave me a nice template, and having tutorials with a similar end product would allow those with Max to do a compare and contrast with a Pd implementation of the same functionality.

I've tried axiome before, and it seemed to work pretty well. I have been thinking about making a granular timestreching looper mlr-esque sort of application in Pd for a little while. So, I checked out this tutorial to get the looping stuff situated.

I think a mlr tutorial in Pd is a good stepping stone for people to get interested in using Pd instead of Max. I feel like most people are familiar with mlr, and it shows people that you can accomplish a lot of the same things in Pd as in Max.

Don't get me wrong. Such tutorial is really neat. I just wanted to point to axiome to avoid duplicate work if people wanted a more advanced app.

Just updated the introduction of tutorial to include a link to axiome (thanks again, jul, for reminding me about it!), and a link to to this thread.

@jul - thanks for reminding us about axiome. i have some experience with pd (part of building a laser harp with my son for a school project), am now building a 128 with bibo boards/sparkfun buttons, and wanted to try my hand at developing some monome applications in pd. axiome and the tutorial referenced in this thread are what motivated me to start with mlr. i am also working on a 64 fingers like application in pd to offer 64 (or 128 or 256) bank of samples, with beat match and sequence recorders. it remains to be seen whether i get good enough with pd for these to be of interest to others...

@bongo, if you need any help I can definitely lend a hand.

@BoxieBrown - thanks for the offer. i have been distracted from my pd work for a bit by 1) a big new project at work (damn that reality impinging on my fun!), and 2) arrival of remaining hardware/supplies needed to assemble my 128. i hope to dive back in to pd over the next 2 weekends, and will certainly be in touch about my progress and areas where i might benefit from some help.

perhaps we should start a new thread focused on pd app's for monome?

@BoxieBrown or others-

A newb question... can you explain to me what 'slices', 'length' (in bars) and 'poly' are in the axiome patch? if i am using phasor~ to jump to a position in a sample, with that position being generated by a button press as in this tutorial, do i need to be concerned with slices? does length in axiome simply refer to the number of times (bars) a sample will loop for a single progression across the eight positions? and poly?

how does the switch-ramp method sound? i'm very intrigued by this approach.

I think I can answer all these questions.

So, what weng is doing here, is breaking up the playback into "slices". Instead of giving a start and end point to a line~ for the entire sample, it gives start and end points for each "slice". It counts up (or backwards) through the number of slices. So, think about it like, play first slice from time 0ms to time 99ms, play second slice from time 100ms to time 199ms, and so on. This makes it so you can change the master tempo and not affect the pitch of the sample.

Long story short, if you're just using phasor~ to jump to points in a sample you don't need to be concerned with slices.

Length is just a measurement used for determining the correct playback speed. So, instead of saying your sample is 44,100 samples long, it's using a more abstract measurement of "bars", which makes more sense musically.

If you look in [pd sample_playback] in the slicer.pd abstraction there are 3 subpatches [pd play-0] , [pd play-1], etc. and essentially they're just 3 different sample playbacks. Though, I'm not really sure how this affects the sound.

Also, I agree, we should probably just start another thread for pd apps.

@tehn I think it sounds alright. I do notice some clicks on certain samples, but they don't appear to be very obtrusive. Though, in some cases I think it sounds very smooth.

@tehn - to my ears, the switch-ramp method sounds much smoother than no method at all. as BoxieBrown points out, i do occassionally notice some discontinuities with some samples.

@BoxieBrown - thanks for the info. still not clear on axiome's use of length in bars. to continue with your example, if using a sample 44,100 samples long (i.e., 1 sec at 44.1K sample rate) in slot one and another sample 88,200 samples long in slot two (2 sec), what does a bar represent here and how would i use this setting in Axiome?

Also, any info about what poly is?

@bongo - bars is what axiome uses to determine how fast/slow you should play a sample back. So, to use it correctly, if you have a drum sample that's 4 beats / 1 bar long, set this to 1 bar. If you want to play to back at half the tempo, set it to 2 bars. When you load a file into axiome it grabs the sample length, and you have to give it the desired length. This determines how fast/slow it plays the sample.

Using the example from before, say somehow a bar of music fit into a second of time (that'd be really fast, but let's just go with it). Then a two second sample at that same tempo would have two bars of music. All in all, if you want to play back the sound at the tempo it was recorded, in our example, 1 bar would be the setting for slot 1, and 2 bars would be the setting for slot 2.

I'm not sure if poly is implemented how weng envisioned it. From what I can see, if you set poly to 3, every time a slice should occur a bang gets sent to a counter, and this number (0 to 2) determines which of the sample playback subpatches are triggered. I could be missing something, but I don't hear a difference in the sound by changing the poly number

@BoxieBrown - thanks yet again. would you be willing to share your email so i can continue this conversation with you offline. you can contact me at bongoATcosmiccasbahDOTcom.

Not to resurrect this thread, but I really, really love this patch as a means of demonstrating to people how to cover the basics.

It makes me wonder -- what about a set of basic sample playback abstractions? They in turn could be used to do things that perhaps even MLR does not. I guess the most logical starting place would be a granular playback abstraction.

Alternatively, in addition to micro-looping I suppose actual looped playback could be useful. I recall an external with this purpose that worked on both Max/Pd, but can't find it now... and there's some advantage to sticking with tabread~ for portability.

There's also some great stuff in the RjDj Composers' Toolkit and on RjDj's SVN, all open source-licensed. There's actually *too much* great stuff; still digging through it all. :)

Hi all,

Haven't been here for a big while. Various reasons. Not interesting.

@ucacjbs: Kudos for your tutorial. Very well explained. Would have saved me a lot of head-scratching when making axiome.

It was my first attempt to an app for the monome, so I know it's far from perfect. It's inefficient and in some ways buggy. Maybe it was too soon in my pd learning curve. :p

@Boxiebrown has it right for the various obscure options of axiome.

A precision on poly though.

In a slot (or sample if you wish), there are 3 playback subpatches alternating. In each playback subpatch ([pd play-X]), there are two playback systems again alternating between each other. Each of this sub-system cuts the output of the other one when hit by a new slice.

So Poly set to one will stay in [pd play-0], alternating between the two sub-systems within and cut the en of the sample, in case the playback is faster than the actual sample tempo.

Poly set to 2 or 3 will actually enable the other playback subpatches [pd play-1] and [pd play-2]. So when a new slice hits the next subpatch, the latter will choose one of his two subpatches and playback the slice with it.
This will NOT cut the other(s) subpatch(es) ([pd play-1] and [pd play-2]), allowing the slice to reach his end, and overlapping the next one. This allows a more natural sounding of samples containing sounds that have tails.

When I think about it, this could be a start for maaaad app, really.

It does what I headed to, but does it badly. Too many artefacts.

Herm, when I looked again in axiome today I said to myself:"wow, was I really doing this messy stuff". You gotta agree, it's pretty messy.

In fact, if I were to make it again (maybe I am going to), I'll go another way. Simpler, more efficient and cpu-friendly way.

I'll start first by implementing a better timing/clock handler ;) .

Then I would completely extract the monome stuff from the engine and control the engine with OSC messages (like /axiome/track1/playback [playback_pos]). So that any gui could be made around with any programming language supporting OSC.

Then [put other ideas here]...

Anyways I'd be glad to share some experiments and useful abstractions I've made, as well as learn from others or contribute to their projects, or simply help. SHARE is the word.

I felt way too much lonely in my monome/pd journey.

Oh and I'm running Linux, so max/msp or Live/OSC is not really an option for me.

@bongo: you made the apps you were planning in Nov?

Excuse the long post.

Greetings

@weng - 1st: many thanks to you for creating axiome, as i learned a lot about pd from this.

i did indeed "complete" a version of mlr in pd, which can be found here: http://post.monome.org/comments.php?DiscussionID=7177&page=1#Item_27
there have been a few suggestions made for fixes/improvements that i haven't gotten to yet.

i also started work last fall on a step sequencer and something like 64 fingers, both in pd, but i haven't touched them for a few months... i finished my 128 kit and have been spending what time i have for this stuff participating in the last two monome community remix projects (MCRP V3 and V4). i'll get back to my pd work soon...

Some how I've kind of lacked on this thread for a while.

@weng - your poly description clears up the functionality. I really like the idea of having other elements be OSC controlled, like the gui. A processing gui might be cool.

@peterkirn - 1. I love createdigitalmusic, 2. I agree, there are a lot of great things happening with RjDj (I actually applied for a job with them a year ago or so). I don't have an iPhone, but the composers toolkit is extremely useful. I've used some of their abstractions in normal Pd projects. Also, I think a granular looping abstraction would be quite do-able.

Perhaps we need a monome Pd toolkit to get others interested in creating apps with it.

@BoxieBrown: I'm totally sold on your last statement !
And I have lots to share in this regard.

There is one for almost every programming environment used to create apps for the monome. Why not pd ? :)

I'm ok to put it all online, but maybe we should merge all the stuff we do to avoid duplicate effort and not reinvent the wheel each time. And I don't know (read:don't think) if the monome wiki is the best place to do this (handling of files, versions, etc).

Maybe setting up an SVN server somewhere and making releases with proper documentation on the Monome wiki would be a good way to go.

Count me in! We should probably move over to a new discussion for this subject.

sorry for the tedious comment ive been looking for forums of people using pure data and monome are there any tutorials or guidances people know of to help just link the monome to pure data

thank you

I started with these videos http://www.youtube.com/playlist?list=PL12DC9A161D8DC5DC by Rafael Hernandez and found them more helpful than most of the written pd tutorials.

There are no grid-centric tutorials, though he does do one on OSC routing. I posted a pd monome connector app here a few days ago (serialosc_pd) that demonstrates how to send OSC messages to a grid in PD.