audio error when external monitor is plugged in
dbE2.wav dbE1.wav A2.wav C2.wav A1.wav G2.wav D2bass.wav C3pizz2.wav B1pizz.wav E2pizz.wav Fsharppizz.wav
Hi David, Thanks so much. I've uploaded the sound files, as they're quite small. It'll make it easier as they'll just loadbang into the tables if you have them in the same folder. I really appreciate your looking at that. I'll have a look at those links carefully. -George
Help regarding a loop (I'm very new)
@Simone This will do it, although 200 and 260 are repeated once. If that is a problem you can remove the second one with [change] after the [i].......... but the timing is then incorrect.
200_260.pd ... vanilla
But here is a better option, that is more cpu friendly........ and accurate.
200_260again.pd
And using [moses] .... 200_260moses.pd
I like this challenge..... it is forcing me to look for ways to do stuff in Vanilla.
I like this one best.... it's smaller...... you will have to drag the bits apart to see what is happening.
200_260compact.pd
As an abstraction bounce 3.zip (final maybe).
Of course, it's a trivial exercise in Pd extended...... 200_260ext.pd
David.
Using SSSAD preset system with abstraction arrays
Hi @whale-av thanks for this, this has really helped. I've tried to get it interacting with the SSAD system. So I've produced an abstraction called presetable to sit inside a 'working project' called presettablescreen.
The contents of the presetable abstraction is below
So I can't figure out how to get the {sssad $1/table] object to output the table list (from the textfile (tablesettings.txt) and rewrite it into the [tabwrite $0-table1] object.
The contents of the textfile is below:
My presettable workspace project is below to using the SSSAD subpatch to create the textfile etc.
Any ideas would be great. I've included the patches in this post.
presettable.pd
presettablescreen.pd
tablesettings.txt
cheers
Casper
pd open
Hi David, I am also David.
m0oonlib doesn't come with Pd-vanilla, but I am willing to get Pd-extended working (I'm actually prototyping for a patch that will run on a raspberry pi.) I definitely want to share these patches when I'm done, so I am using relative paths because I want it to run on different environments, with different file structures, with everything relative to the main patch.
If I declare /synths
wouldn't that be an absolute location (at the root of my filesystem?)
open
messages require 2 params, the second of which is the path. If you leave it off you will get this error:
Bad arguments for message 'open' to object 'pd'
I have tried it several ways, and all do not work:
(I get the Bad Argument
error)
With all of these I get Device not configured
:
These work, but are not ideal:
I'd prefer not hardcoding an absolute path.
moonlib/absolutepath
doesn't seem to work with a directory name, only a file. That means this works:
But not this (the format I actually need for path):
This works, but really I'd just prefer a solution that works in Pd-vanilla:
how does [list drip] actually work?
Hi folks,
This is going to be a weird and long post, because I am walking through my thinking as much as I am asking questions. Sorry for the length in advance.
I've recently become fascinated with the many possibilities afforded by the list-abs library, and what strikes me at is that [list-drip] seems to be at the heart of most of them. For those of you who don't know, [list-drip] works by separating (aka "dripping") an incoming list into its individual elements (atoms?). This allows you to do a bunch of operations on these elements before repacking them into a new list. For example, [list-compare] functions like [==] but for lists by checking each list's elements against each other to give out a binary yes or no answer. And of course, [list-drip] is at the core here.
I would like to really figure out the logic behind [list-drip], but the help file (well, really the abstraction itself) is deceptively simple. This is because [list-drip] itself is but an abstraction based on the clever use of [list-split] (which is not an abstraction but an external) and some strange binary math and triggering mechanisms that I don't understand.
Here's the [list-drip] extraction itself:
I'll just talk about this abstraction and ask questions along the way.
Here's the first part. Pretty simple. [trigger] is passing the entire list on, and then sending a bang. This seems weird but I've heard that pd will take care of all the operations starting at the right outlet of trigger first, so the bang is guaranteed to come after the list has been "dripped."
Here's the second part, where we have [list split] doing a binary "less than" operation on the list. "If the list is less than 2 elements long, it gets sent to the outlet and the [spigot] closes, else, open the spigot." This [trigger] then passes a copy of the list onto [spigot] which is either open or closed based on the above result.
Ok now here is where things start to get crazy. The list is now fed into two identical [list split] mechanisms with some weird math going on, which are also feeding back into the top of the second [trigger].
Let's break this down really quick:
First, we get the length of the list, then we feed it into [>> 1]. With some research in pd and the on the web, I come to the conclusion that we are basically dividing (integer division) by 2. This is setting the point for where [list split] outputs a list with only a certain number (but always half) of elements (using the first outlet). As I said before, this result is being fed back into the second [trigger].
So I think basically what's happening is this:
...where the rest of the list is either exactly half the total list length (if it's an even number) or half + 1 (if the total length is an odd number of elements).
So we have two "loops" going on here, where on operates on the first half of the list (will call this the "red" loop, and the other operates on the second "green loop".
Now in terms of trigger ordering, what is happening here? Are we constantly triggering the red loop until there are no more operations, and then moving on the green loop? And what does this mean in the context of the patch? I'm confused about how [trigger] acts in these situations with many nested loops.
To troubleshoot, I attached a print the outlets of both the red and green **[list split]**s, and sent the list [a b c d 1 2 3 4( to [list drip]. Here's the output from the console:
first half: symbol a
second half: symbol b
first half: list a b
first half: symbol c
second half: symbol d
second half: list c d
first half: list a b c d
first half: 1
second half: 2
first half: 1 2
first half: 3
second half: 4
second half: 3 4
second half: 1 2 3 4
To me this output looks like it was printed backwards. Is there some weird interaction between [trigger] and [print] going on?
Furthermore, how is the output of [list drip] organized so that each element is output in it's sequential order? How does the green loop know to wait for the red loop to finish?
Korg NanoKontrol abstraction
I rise out from the ashes my super patch. Here it is for you all, the ultimate sampler patch for the korg nanokontrol :
chano.pd
smp.pd
sceneSample.pd
et-moi.wav
nanoKon-base.nktrl_set
nanoKon-base.nktrl_data
Open "sceneSample". You just need to replace the filenames in the smp boxes with yours. There is a sensivity slider at the right side of the orange knob now. Feel free to share it. It is a super cheap controler turned into a sampler with the ability to change the pitch, the volume and loop or trigger the sample. If nothing is triggered, the pitch comes back to his original value.
.MOV/.MP4 glitcher
Hi,
I have built a pd abstraction that glitches .MOV/.MP4 files. This is the result of a long process that involved the study and understanding of the way .MOV files work and their atom structure. Having learned a lot while developping my jpeg and mp3 glitchers, I have been willing to transpose this knowledge to the video realm. To make a long story short, my abstraction locates the mdat atom of the file, reads its length and glitches it in a user-controlable way, while leaving the rest of the filestructure untouched, allowing various degrees of glitchiness with very few unreadable files.
Of course, the bigger the files, he longer the processing time. I have able to glitch a 250 meg MP4 (40 minutes of video) in a bout 1 minute on a macbook pro running under OS 10.10 with the latest stable version of PD extended. On slower computers, processing may take up to 5/6 minutes. Also note that results will vary according to the codec used for compression. I have been able to get good results with H264, but they should all work. As usual with glitch, results will also vary according to the player you use. I personnaly prefer VLC . Some files may appear broken on some players and play just fine on others... Usually, if a file breaks in the process, just tweak the settings a bit to get less glitched file, it should work eventually. This is particulary thrue with small files.
Here's a bunch of stills I took from one processed video:
Here's the pd extend abstraction:
mp4glitcher.pd
It's a graph on parent abstraction, so the idea is to open it like an object in a blank canvas.
And here's the standalone version for mac:
https://1drv.ms/u/s!AjNgShvVLV0XikkivHwWok_tpbYQ
Your comments are welcome!