PMPD wouldn't work
Good day,
has anyone here ever tried using pmpd on later MacOS? Mine doesn't seem to work giving this message every time I try to create a pmpd object:
... couldn't create
/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin: dlopen(/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin, 0x000A): tried: '/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (no such file), '/Users/fyodor-st/Downloads/pmpd 2/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64'))
/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin: dlopen(/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin, 0x000A): tried: '/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (no such file), '/Users/fyodor-st/Documents/Pd/externals/pmpd/iAmbient2D.pd_darwin' (mach-o file, but is an incompatible architecture (have 'i386', need 'arm64'))
I've been using Pure Data for a couple of years now and feel more or less comfortable with it, but have no actual background in coding of any kind, so any help figuring out what this means and whether this is fixable would be really appreciated!
phase index of an oscillator and 1 sample delay in pd?
@KMETE
the Max patch looks like feedback-FM to me. For PM the + would be placed between phasor and circle, if I'm not mistaken.
And with 1000 ms delay, as I read the Max patch? there would be no need for 1 sample-blocks.
A thread on this topic:
https://forum.pdpatchrepo.info/topic/6185/feedback-fm-algorithm
DC-blocking you can do with [hip~ 20] for example (I'd put it in the feedback-loop).
cycle object
[cos~] ? Is a cosine-tabel, to get a sine you can drive it like this:
[phasor~]
|
[-~ 0.25]
|
[cos~]
Offtopic: Pd's cosine has a slight DC-offset.
https://forum.pdpatchrepo.info/topic/13709/bug-osc-cos-circle-asymmetry-drifting-out-of-phase
@alexandros said:
Creating a one-sample delay is achieved by placing your objects in a subpatch and putting a
[block~ 1]
object in there. Then you have to use[tabsend~]
and[tabreceive~]
instead of[delwrite~]
and[delread~]
to achieve the one-sample delay.
Yes. And be aware of the importance of creating [tabsend~] beforehand of [tabreceive~] . You can read about in the Pd documentation 3.audio.example > G05.execution.order.pd
For feedback, I usually build subpatches with such a dummy-connection, save the patch, and delete the dummy cable lastly and save again, for perceving the execution order and avoiding a dsp-loop.
[delwrite~] and [delread~] can become as short as 1 sample, too.
In both [osc~] and [phasor~], the phase is set by control messages, but since you'll have a one-sample block size, that shouldn't be a problem, you can just set the phase to what ever you like and it will be reset at the next sample block (one sample later).
This is one of the biggest myths in Pd (at least for me), but unfortunately not true. (Vanilla 52.2)
See vphasor~-help : https://github.com/dotmmb/mmb
Still the same, if you put it in a subpatch with [block~ 1].
Documentation is lacking here. There are very few timing- sample- or phase-critical control-objects that are able to update (sub-)sample-accurately in-between block-boundaries of 64 samples minimum:
I only know of [bang~], [metro], [delay], [pipe], [vline~]
Why does Pd look so much worse on linux/windows than in macOS?
@danomatika said:
@seb-harmonik.ar Yeah, I noticed this too. Miller reverted it for some reason. I have pinged him on Github to ask for the reason.
From the comment in the source code, it seems that some users frequently do:
- Ctrl-D to duplicate an object.
- Mouse move.
- Retype immediately into the object box.
... which, with the "no-edit" change, requires an extra click.
(My suspicion here is that "some users" = only Miller Puckette, but anyway.)
In github, I had commented two months ago that this really should be a user preference.
Now, granted... unpaid open source project, volunteer development, a couple of months inactivity on a non-critical issue is not at all surprising. So I wouldn't read anything into non-response.
It may be helpful for other forum users to comment on the github issue. Where it stands now, in github, is that there's MSP's view (which looks to me like "I want mouse-move-edit, and it's my project"), one grumpy user (myself) strongly opposing it, and a couple of votes in favor of a user preference. Because it takes developer time to add a user preference, it may require input from more users -- currently there's not enough demand for them to take the time, but if 20 users ask for the same change, then that's different.
hjh
Convert analog reading of a microphone back into sound
@MarcoDonnarumma Good luck.....!
Further to my post above... re block boundaries...... 500Hz is close to the maximum sample rate you can send.
At a block size of 64..... 44100/64 = 689.0625 will be the maximum possible sample rate from the Arduino that Pd can process with control rate data (without a timestamp).
With a timestamp to properly separate the values........ stopping previous messages being overwritten when a new message arrives before the block boundary..... [vline~] could set the future sample values from the separated messages (it can queue them...... schedule any number of future ramps) at 44100 single sample accuracy........
Then you could send from the Arduino at a higher sample rate..... with the limit being set by the osc receive socket... which might if you are lucky be higher than the sample rate you are sending.
You might then need to set priorities in your router to get more reliability for the UDP messages (fewer packets lost).
The accuracy that you gain with the timestamp will allow @jameslo 's patch to work properly with the addition of [vline~] as @manuels says.
I will have a look at @manuels's patch later...... you will beat me to it.
That you had some result with [lop~] shows that we are on the right path...
David.
P.S. Router throughput seems high enough. Here is info on router tweeking if you need to...... https://support.tetcos.com/support/solutions/articles/14000121108-what-are-the-settings-to-get-max-throughput-udp-tcp-for-802-11n-and-802-11ac-
Convert analog reading of a microphone back into sound
@MarcoDonnarumma Just had a cursory look at you video.... very good.
So you will understand more musical tech terms.
With your low sample rate the steps in the waveform are massive. The result is approximately what you would ask of a "fuzz" box.
Your ears only hear the rapid changes where the waveform rises or falls vertically. Your brain can only interpret the audio that way as it gets no intermediate information.
A rapid rise or fall like those you see in the scope are..... because the signal rate is now (after [sig~] ) 44100 samples per second..... actually a very high frequency signal....... one half (the left or right half) of a 22KHz "note".
Usually called "aliasing"...... they are there because there was no information before or after to give the real analogue slope of the wave before it was sampled.
For CD audio the rate is also 44100Hz. The Nyquist is 22050Hz and a low pass filter in the DAC removes everything above 20000Hz so as to remove such artefacts.
Putting a [lop] will smooth out those steps and approximate the original waveform as it was originally sampled. The downside is that you will no longer hear the audio because it is likely outside the range of most peoples hearing (in this case only!.... with audio below 40Hz..... if it was a 200Hz note you would hear it).
If you put a [lop~] (between [sig~] and [dac~] with a fader connected to its right inlet with a range of say 0.3 to 40 you can play with the fader to get an audible signal that is close to what you want to hear.
A sort of "depth of fuzz".
You might need a slightly different range on the fader..... 0.1 to 25 or something.
Looking at your video....... seeing (yes, ok, hearing) that you need audible sound.... not 192KHz audiophile sound.... and bearing in mind the original 40Hz analogue signal is inaudible to a lot of people, I don't think the clock problem is going to have a significant effect.
But if you are mistaken about the 40Hz maximum and there is actually more information that you need....... think heartbeat (low) + blood rushing (high) then upping your sample rate from the arduino will be necessary to get the higher frequencies.
500Hz sample rate will only give you up to 250Hz of audio information, just like 44100Hz only renders 22050Hz for our delectation.
David.
P.S. I don't much like maths..... not true..... it is fascinating but too hard for my feeble brain.
But without bothering to work it out, in theory, to preserve the signal the [lop] should be just below half the nyquist... so for 500Hz sampling a [lop~ 240] ?? should do that.
So I was way off base with the [lop~] values I posted above.
The signal would be very reduced (much lower I think) with the values I gave above.
However, [lop~] is not a very "sharp" filter... low dB/octave...... so maybe I was not in fact wrong...... and anyway you will need some distortion so as to properly hear your 40Hz note.
I hope you like to have someone struggling alongside you while you work.
I have to research what that means when the signal has already been oversampled by [sig~]..... but I think it doesn't matter.
Someone clever will tell us first no doubt.
@jameslo 's solution above should give a better outcome though than with a rather uncertain value for [lop~].
It will depend on what you need from your patch.
Why does Pd look so much worse on linux/windows than in macOS?
@ddw_music said:
I still think Tcl/Tk has failed to keep up with modern standards, and I have my doubts that it will ever catch up. So, I still think that Pd hampers its own progress by hitching itself to the Tcl/Tk wagon.
I think most people agree with you, myself included. Tk is clunky but it's in the current code base and has been kept so far since it works, although admittedly barely in many cases.
The last couple of posts here are encouraging.
I know development is slow, but it's really working against inertia. Momentum has been growing the last years and that's mostly due to more effective collaboration to tackle some of these issues. I think finding a sustainable approach to the GUI is one of the largest ones, so is taking a while to grow.
IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.
Nope. See above.
Developer vs user perspective. The user sees clean diagonals on Mac, and jagged diagonals on Linux or Windows, and I think it's perfectly legitimate for the user not really to care that it's the OS rather than the drawing engine that makes it so in Mac. (It's correct, of course, to point out that the diagonals on a retina display will look smoother than antialiased diagonals without retina.)
Yup, you are totally right. I didn't mean to imply the Linux screenshot looked good since "that's the way it is" just more that it looks so much better on macOS since the screenshot is likely double the resolution as well.
I started using Pd on Windows circa 2006 then jumped to Linux for many years, then to macOS. My feeling was that Pd worked best on Linux but a lot of that has caught up as the underlying systems have developed but in some ways the Linux desktop has not (for many reasons, good and bad).
- Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.
I did try Purr Data, but abandoned it because (at the time, two years ago), Purr Data on Mac didn't support Gem and there were no concrete plans to address that. This might have changed in the last couple of years (has it? -- I've looked at https://agraef.github.io/purr-data/ and https://github.com/agraef/purr-data but it seems not quite straightforward to determine whether Gem+Mac has been added or not).
That's a result of many of the forks adopting the "kitchen sink" monolithic distribution model inherited from Pd-extended. The user gets the environment and many external libraries all together in one download, but the developers have to integrate changes from upstream themselves and build for the various platforms. It's less overheard for the user but more for the developers, which is why integrating a frankly large and complicated external like GEM is harder.
I'm happy to download the deken GEM package because I know the IEM people have done all the craziness to build it (it's a small nightmare of autotools/makefiles due to the amount of plugins and configuration options). I am also very happy to not have to build it and provide it to other users but in exchange we ask people to do that extra step and use deken. I recognize that the whole usage of [declare] is still not as easy or straightforward for many beginners. There are some thoughts of improving it and feedback for people in the teaching environment has also pushed certain solutions (ie. Pd Documents folder, etc).
Tracking vanilla releases was the other issue. A couple of years ago, [soundfiler] in Purr Data was older and didn't provide the full set of sound file stats. That issue had been logged and I'm sure it's been updated since then. "Tracking" seemed to be manual, case-by-case.
By "tracking" I am referring to a fork following the new developments in Pd-vanilla and integrating the changes. This becomes harder if/when the forks deviate with internal changes to the source code, so merging some changes then has to be done "by hand" which slows things down and is one reason why a fork may release a new version but be perhaps 1 or two versions behind Pd vanilla's internal objects, ie. new [soundfiler] right outlet, [clone] object, new [file] object, etc.
- As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.
I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years...
Well, I mean, OK up to a point. There are things like the Tcl/Tk open/save file dialog, which is truly abhorrent in Linux.
Hah yeah, I totally understand. My first contribution to Pd(-extended) was to find out how to disable showing hidden files in the open/save panels on Linux. You would open a dialog, it defaulted to $HOME
, then you had to wade through 100 dot folders. Terrible! Who did this and why? Well it wasn't on purpose, it was just the default setting for panels on Tk, and I added a little but of Tcl to turn it off and show a "Show hidden files/folders" button below.
OTOH I have a colleague at work who's internal toolkit still uses Motif. Why? Well it still works and he's the only user so he's ok with it. I'd say that Tk also still uses Motif... but there are many users and they have much different expectations. ;P
Some puzzling decisions here and there -- for example, when you use the mouse to drag an object to another location, why does it then switch to edit the text in the object box? To me, this is a disruptive workflow -- you're moving an object, not editing the object, but suddenly (without warning) you're forcibly switched into editing the object, and it takes a clumsy action of clicking outside the object and dragging the mouse into the object to get back to positioning mode. I feel so strongly about it that I even put in a PR to change that behavior (https://github.com/pure-data/pure-data/pull/922), which has been open for a year and a half without being either merged or rejected (only argued against initially, and then stalled).
Ah yes, I forgot about this one. It wasn't rejected, just came at a time when there were lots of other things shouting much louder, ie. if this isn't fixed Pd is broken on $PLATFORM. I would say that, personally, your initial posting style turned me off but I recognize where the frustration came from. I also appreciate making the point AND providing a solution, so the ball is in our court for sure. I will take a look at this soon and try it out.
"Still working for 20 years" but you could also say, still clunky for 20 years, with inertia when somebody does actually try to fix something.
Another approach would be to try to bring improvements to Tcl/Tk itself but the dev community is a little opaque, more so than Pd. However I admit to not having put a ton of time into it, other than flagging our custom patches to the TK macOS guy on Github.
WRT to the rest, any architectural improvements (e.g. drawing abstractions so that the Pd core isn't so tightly coupled to Tcl/Tk) that make it more feasible to move forward are great, would love to see it.
As would I... we are preparing for a major exhibition opening in December, but I will have some time off after and I may take a stab at a technical demo for this (among other things) then pull in some other perspectives / testers. It has been an itch I have wanted to scratch since, at least Pd Con 2016 in NYC.
Audio click occur when change start point and end point using |phasor~| and |tabread4~|
@Junzhe-hou said:
@ddw_music Hi professor!?!? good to see you here!
Yes, it's me -- I almost didn't notice your username
I read your email last week but im so confused with your
patch--varispeed-segment:|noise~|
|
|lop~ 3|
|
|*~ 30|
|
|+~ 1|
This is just a way to generate a modulator for the playback rate. It could be any other modulator (LFO, envelope, anything).
After that, this is multiplied by a sample rate scaling factor.
As you asked jameslo: "if sample rate (in audio setting) changed the result sound different":
-
If the file sample rate is 96 kHz and the soundcard sample rate is 96 kHz, then normal-speed playback is to move forward exactly 1 sample in the file for every output sample.
-
If the file sample rate is 96 kHz and the soundcard sample rate is 48 KHz, then normal-speed playback is to move forward exactly 2 samples in the file for every output sample. (If you playback at 1:1, then the file will sound slower at the lower soundcard sample rate.)
This was one of the big reasons for me to make [soundfiler2] in my abstraction set. It calculates file_sr / system_sr
and saves this in a value object named after the ID+"scale". If you multiply the playback rate by this scaling factor, then the file should sound correct at any system sample rate.
(BTW you would have the same issue in SuperCollider: PlayBuf.ar(1, bufnum, rate: 1)
will sound different depending on the hardware sample rate, but PlayBuf.ar(1, bufnum, rate: BufRateScale.kr(bufnum))
would sound the same, except maybe for aliasing when downsampling.)
You method "L inlet = rate * scale for sample increment",so is the rate always changing?
Yes -- variable-speed playback.
@jameslo "I'm sorry if I just did your student's homework" -- actually this isn't for my class -- independent project. There are still some students who do hard things just because it's fun to overcome challenges
hjh
GEM / Catalina
Hello. I can't get GEM to work on MacOS Catalina (10.15.4). I installed using Help > Find Externals. Here're the errors I get. . . .
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
GEM: Graphics Environment for Multimedia
GEM: ver: 0.94.git v0.94_pre1
GEM: compiled on Dec 21 2018
GEM: maintained by IOhannes m zmoelnig
GEM: Authors : Mark Danks (original version)
GEM: Chris Clepper
GEM: Cyrille Henry
GEM: IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM: homepage https://gem.iem.at/
GEM: bug-tracker https://bugs.gem.iem.at/
GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/
GEM: binary/abstractions version mismatch!
GEM: continue at your own risk...
GEM: compiled for MMX/SSE2 architecture
GEM: using SSE2 optimization
GEM: detected 8 CPUs
GEM: image loading support: magick SGI imageIO jpeg tiff
GEM: image saving support: SGI imageIO jpeg magick tiff
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
gemcocoawindow
... couldn't create
Ganymede: an 8-track, semi-automatic samples-looper and percussion instrument based on modulus instead of metro
Ganymede.7z (includes its own limited set of samples)
Background:
Ganymede was created to test a bet I made with myself:
that I could boil down drum sequencing to a single knob (i.e. instead of writing a pattern).
As far as I am concerned, I won the bet.
The trick is...
Instead of using a knob to turn, for example, up or down a metro, you use it to turn up or down the modulus of a counter, ie. counter[1..16]>[mod X]>[sel 0]>play the sample. If you do this then add an offset control, then where the beat occurs changes in Real-Time.
But you'll have to decide for yourself whether I won the bet. .
(note: I have posted a few demos using it in various stages of its' carnation recently in the Output section of the Forum and intend to share a few more, now that I have posted this.)
Remember, Ganymede is an instrument, i.e. Not an editor.
It is intended to be "played" or...allowed to play by itself.
(aside: specifically designed to be played with an 8-channel, usb, midi, mixer controller and mouse, for instance an Akai Midimix or Novation LaunchPad XL.)
So it does Not save patterns nor do you "write" patterns.
Instead, you can play it and save the audio~ output to a wave file (for use later as a loop, song, etc.)
Jumping straight to The Chase...
How to use it:
REQUIRES:
moonlib, zexy, list-abs, hcs, cyclone, tof, freeverb~ and iemlib
THE 7 SECTIONS:
- GLOBAL:
- to set parameters for all 8 tracks, exs. pick the samples directory from a tof/pmenu or OPEN_IND_DIR (open an independent directory) (see below "Samples"for more detail)
- randomizing parameters, random all. randomize all every 10*seconds, maximum number of bars when randomizing bars, CLR the randomizer check boxes
- PLAY, L(imited) or I(nfinite) counter, if L then number of bars to play before resetting counter, bpm(menu)
- MSTVOL
- transport/recording (on REC files are automatically saved to ./ganymede/recordings with datestamp filename, the output is zexy limited to 98 and the volume controls the boost into the limiter)
- PLAYHEADS:
- indicating where the track is "beating"
- blank=no beat and black-to-red where redder implies greater env~ rms
- MODULAE:
- for information only to show the relative values of the selected modulators
- WEIGHTS:
- sent to [list-wrandom] when randomizing the When, Accent, and Offset modulators
- to use click READ_ARRAYS, adjust as desired, click WRITE, uncheck READ ARRAYS
- EVEN=unweighted, RND for random, and 0-7 for preset shapes
- PRESETS:
- ...self explanatory
-
PER TRACK ACCORDION:
- 8 sections, 1 per track
- each open-closable with the left most bang/track
- opening one track closes the previously opened track
- includes main (always shown)
- with knobs for the sample (with 300ms debounce)
- knobs for the modulators (When, Accent, and Offset) [1..16]
- toggles if you want that parameter to be randomized after X bars
- and when opened, 5 optional effects
- adsr, vcf, delayfb, distortion, and reverb
- D-W=dry-wet
- 2 parameters per effect
-
ALL:
when ON. sets the values for all of the tracks to the same value; reverts to the original values when turned OFF
MIDI:
CC 7=MASTER VOLUME
The other controls exposed to midi are the first four knobs of the accordion/main-gui. In other words, the Sample, When, Accent, and Offset knobs of each track. And the MUTE and SOLO of each track.
Control is based on a midimap file (./midimaps/midimap-default.txt).
So if it is easier to just edit that file to your controller, then just make a backup of it and edit as you need. In other words, midi-learn and changing midimap files is not supported.
The default midimap is:
By track
CCs
---TRACK--- | ---SAMPLE--- | ---WHEN--- | ---ACCENT--- | --- OFFSET--- |
---|---|---|---|---|
0 | 16 | 17 | 18 | 19 |
1 | 20 | 21 | 22 | 23 |
2 | 24 | 25 | 26 | 27 |
3 | 28 | 29 | 30 | 31 |
4 | 46 | 47 | 48 | 49 |
5 | 50 | 51 | 52 | 53 |
6 | 54 | 55 | 56 | 57 |
7 | 58 | 59 | 60 | 61 |
NOTEs
---TRACK--- | ---MUTE--- | ---SOLO--- |
---|---|---|
0 | 1 | 3 |
1 | 4 | 6 |
2 | 7 | 9 |
3 | 10 | 12 |
4 | 13 | 15 |
5 | 16 | 18 |
6 | 19 | 21 |
7 | 22 | 24 |
SAMPLES:
Ganymede looks for samples in its ./samples directory by subdirectory.
It generates a tof/pmenu from the directories in ./samples.
Once a directory is selected, it then searches for ./**/.wav (wavs within 1-deep subdirectories) and then ./*.wav (wavs within that main "kit" directory).
I have uploaded my collection of samples (that I gathered from https://archive.org/details/old-school-sample-cds-collection-01, Attribution-Non Commercial-Share Alike 4.0 International Creative Commons License, 90's Old School Sample CDs Collection by CyberYoukai) to the following link on my Google Drive:
https://drive.google.com/file/d/1SQmrLqhACOXXSmaEf0Iz-PiO7kTkYzO0/view?usp=sharing
It is a large 617 Mb .7z file, including two directories: by-instrument with 141 instruments and by-kit with 135 kits. The file names and directory structure have all been laid out according to Ganymede's needs, ex. no spaces, etc.
My suggestion to you is unpack the file into your Path so they are also available for all of your other patches.
MAKING KITS:
I found Kits are best made by adding directories in a "custom-kits" folder to your sampls directory and just adding files, but most especially shortcuts/symlinks to all the files or directories you want to include in the kit into that folder, ex. in a "bongs&congs" folder add shortcuts to those instument folders. Then, create a symnlink to "bongs&congs" in your ganymede/samples directory.
Note: if you want to experiment with kits on-the-fly (while the patch is on) just remember to click the REFRESH bang to get a new tof/pmenu of available kits from your latest ./samples directory.
If you want more freedom than a dynamic menu, you can use the OPEN_IND(depedent)_DIR bang to open any folder. But do bear in mind, Ganymede may not see all the wavs in that folder.
AFTERWARD/NOTES
-
the [hcs/folder_list] [tof/pmenu] can only hold (the first) 64 directories in the ./samples directory
-
the use of 1/16th notes (counter-interval) is completely arbitrary. However, that value (in the [pd global_metro] subpatch...at the noted hradio) is exposed and I will probably incorporate being able to change it in a future version)
-
rem: one of the beauties of this technique is: If you don't like the beat,rhythm, etc., you need only click ALL to get an entirely new beat or any of the other randomizers to re-randomize it OR let if do that by itself on AUTO until you like it, then just take it off AUTO.
-
One fun thing to do, is let it morph, with some set of toggles and bars selected, and just keep an ear out for the Really choice ones and record those or step in to "play" it, i.e. tweak the effects and parameters. It throws...rolls...a lot of them.
-
Another thing to play around with is the notion of Limited (bumpy) or Infinite(flat) sequences in conjunction with the number of bars. Since when and where the modulator triggers is contegent on when it resets.
-
Designed, as I said before, to be played, esp. once it gets rolling, it allows you to focus on the production (instead of writing beats) by controlling the ALL and Individual effects and parameters.
-
Note: if you really like the beat Don't forget to turn off the randomizers. CLEAR for instance works well. However you can't get the back the toggle values after they're cleared. (possible feature in next version)
-
The default.txt preset loads on loadbang. So if you want to save your state, then just click PRESETS>SAVE.
-
[folder_list] throws error messages if it can't find things, ex. when you're not using subdirectories in your kit. No need to worry about it. It just does that.
POSTSCRIPT
If you need any help, more explanation, advise, or have opinions or insight as to how I can make it better, I would love to hear from you.
I think that's >=95% of what I need to tell you.
If I think of anything else, I'll add it below.
Peace thru Music.
Love thru Pure Data.
-s
,
I don't understand \[fexpr~\]?
@Obineg [fexpr~]
is quite a bit less efficient than [expr~]
so, if you don't need per-sample memory or feedback it is much better to use [expr~]
why? because in order to store each of the output samples for the current processed sample, [fexpr~]
needs to operate on single passes of the perform loop, then store the input and output samples.
I think since [expr~]
deals with a block (vector) of samples it is generally more efficient since it can pipeline and vectorize the actual instructions. And it's not possible to do that if the next output sample is dependent on the current output sample.
plus, due to the way pd uses the input and output samples in a dsp graph, the input and output buffer might be the same buffer. This means that if you want to read an input sample from the past you first have to store it somewhere to make sure it won't be overwritten when writing to the output. so [fexpr~]
also has to do that when [expr~]
doesn't (since [expr~]
only processes input samples as a vector).
basically: [expr~]
operates on the whole vector/block (meaning the constituent functions/operators are applied "at once" over the vector/block for every part of the computation), [fexpr~]
operates on the individual samples of that vector/block. (meaning the constituent functions/operators are applied in turn to every sample in the block, one at a time, for every part of the computation)