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
,
banging [switch~] performs audio computations offline!
According to block~ help, if you bang [switch~] it runs one block of DSP computations, which is useful for performing computations that are more easily expressed as audio processing. Something I read (which I can't find now) left me with the impression that it runs faster than normal audio computations, i.e. as if it were in control domain. Here are some tests that confirm it, I think: switch~ bang how fast.pd
The key to this test is that all of the bangs sequenced by [t b b b b] run in the same gap between audio block computations. When [switch~] is banged, [osc~] fills array1, but you can see that element 63 of array1 changes after [switch~] is banged. Furthermore, no logical time has elapsed. So it appears that one block of audio processing has occurred between normal audio blocks. [bang~] outputs when that accelerated audio block processing is complete.
This next test takes things further and bangs [switch~] 10 times at control rate. Still, no logical time elapses, and [bang~] only outputs when all 10 bangs of [switch~] are complete. [rzero_rev~ 0] is just an arcane way of delaying by one sample, so this patch rotates the contents of array1 10 samples to the right. switch~ bang how fast2.pd
(There are better ways to rotate a table than this, but I just needed something to test with. Plus I never pass up a chance to use [rzero_rev~ 0] )
Finally, I've seen some code that sends a 1 to [switch~] and then sends 0 after one block of processing. In this test you can see that one block of audio is processed in one block of logical time, i.e. the normal way. switch~ bang how fast3.pd
But that second test suggests how you could embed arbitrary offline audio processing in a patch that's not being run with Pd's -batch flag or fast-forwarded with the fast-forward message introduced in Pd 0.51-1. Maybe it's an answer to two questions I've seen posted here: Offline analysis on a song and Insant pitch shift. Here's a patch that writes 20s of 440 Hz to a file as fast as possible (adapted from @solipp's patch for the first topic). You just compute how many blocks you need and bang away. write440File.zip
Here's another that computes the real FFT of an audio file as fast as possible: loadFFT.zip
But as with any control rate processing, if you try to do too much this way, Pd will fall behind in normal audio processing and stutter (e.g. listen to the output while running that last patch on a >1 minute file). So no free lunch, just a little subsidy.
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)
Just Another (Drum) Sequencer...SortOf, codename: Virgo
Just Another (Drum) Sequencer...SortOf, codename: Virgo
REQUIRES: zexy, moonlib, tof (as of Pd 0.50.2, all of which are in deken) and hcs (which comes by default with Pd 0.50.2 and is in deken (for extended))
Special Features
- Unique playhead per row; each with their own metro (beat)
- Up to 8 Volume states-per-beat (by clicking multiple times on the bang; where an rms=1 is divide among the states (2 states:0=rms=0(black), 1=rms=1(red); 3 states:rms=[0|0.5|1])
- Design approach: using creation arguments to alias abstractions, so subsequently they are referred to by their creation arguments, ex. in [KITS sample] sample is referred to as [$1]; which is how they are listed below)
(notes: what I learned experimenting with this design approach, I will share as a separate post. Currently, it does not include cut-copy-paste (of regions of the pattern)). I good way to start trying it out is clicking the "R" to get a random kit and a random pattern).
virgo:[virgo/PROJECT KITS PATTERNS]
- PROJECT[KITS PATTERNS]
- $1:[KITS sample]
- GUI
- K: openpanel to load a previously saved *.txt (text object) kit of samples; on loadbang the default.txt kit is loaded
- S: save the current set of samples to the most recently opened *.txt (kit) preset
- SA: saveas a *.txt of the current set of samples
- D: foldererpanel a sample directory to load the first (alphabetically) 16 samples into the 16 slots
- RD: load a random kit from the [text samples] object where the samples where previously loaded via the "SAMPLES" bang on the right
- U: undo; return to the previously opened or saved *.txt kit, so not the previously randomized
- MASTER: master gain
- (recorder~: of the total audio~ out)
- record
- ||: pause; either recording or play;
- play: output is combined with the sequencer output just before MASTER out to [dac~]
- SAMPLES: folderpanel to load a (recursive) directory of samples for generating random kits
- ABSTRACTIONS
- $1: sample
- bang: openpanel to locate and load a sample for a track
- canvas: filename of the opened sample; filenames are indexed in alignment with track indices in the PATTERNS section
- $1: sample
- GUI
- $2:[PATTERNS row]
- GUI
- P: openpanel to load a previously saved *.txt (pattern) preset file; on loadbang the default.txt pattern is loaded; the preset file includes the beat, pattern, and effect settings for the row
- S: save the current pattern to the most recently opened pattern .txt
- SA: save as (self-explanatory)
- states: the number of possible states [2..8] of each beat;
- %: weight; chance of a beat being randomized; not chance of what it will result in; ex. 100% implies all beats are randomized ; random beats result in a value)gain) between 1 and states-1
- PLAY(reset): play the pattern from "start" or on stop reset all playheads to start
- start: which beat to start the playheads on
- length: how many beats to play [+/-32]; if negative the playheads will play in reverse/from right to left
- bpm: beats-per-minute
- rate: to change the rate of play (ie metro times) by the listed factor for all playheads
- R: randomize the total pattern (incl period and beats, but not the effect settings; beats of 1/32 are not included in the possibilities)
- CL: clear, set all beats to "0", i.e. off
- U: undo random; return to the previously opened or saved preset, ie. not the previous random one
- M: mute all tracks; the playheads continue moving but audio does not come out of any track
- ||:pause all playheads; play will resume from that location when un-paused
- per: period; if 0=randomizes the period, >0 sets the period to be used for all beats
- Edit Mode
- Check the [E] to enter edit mode (to cut, copy, or paste selected regions of the pattern)
- Entering edit mode will pause the playing of the pattern
- Play, if doing so beforehand, will resume on leavng edit mode
- The top-left most beat of the pattern grid will be selected when first entering edit mode
- Single-click a beat to select the top-left corner of the region you wish to cut or copy
- Double-click a beat to select the bottom-right corner
- You may not double-click a beat "less than" the single-clicked (top-left) beat and vice-versa
- Click [CL] to clear your selection (i.e. start over)
- The selected region will turn to dark colors
- If only one beat is selected it will be the only one darkened
- Click the operation (bang) you wish to perform, either cut [CU] or copy [CP]
- Then, hold down the CTRL key and click the top-left corner of where you want to paste the region
- The clicked cell will turn white
- And click [P] to paste the region
- Cut and copied regions may both be pasted multiple times
- The difference being, cutting sets the values (gains) for the originating region to "0"
- Click [UN] to undo either the cut, copy, or paste operation
- Undoing cut will return the gains from 0s to their original value
- Check the [E] to enter edit mode (to cut, copy, or paste selected regions of the pattern)
- (effect settings applied to all tracks)
- co: vcf-cutoff
- Q: vcf-q
- del: delay-time
- fb: delay-feedback
- dist: distortion
- reverb
- gn: gain
- ABSTRACTIONS
- $1: [row (idx) b8] (()=a property not an abstraction)
- GUI
- (index): aligns with the track number in the KITS section
- R: randomize the row; same as above, but for the row
- C: clear the row, i.e. set all beats to 0
- U: undo the randomize; return to the originally opened one, ie. not the previous random one
- M: mute the row, so no audio plays, but the playhead continues to play
- S: solo the row
- (beat): unit of the beat(period); implying metro length (as calculated with the various other parameters);1/32,1/16,1/8, etc.
- (pattern): the pattern for the row; single-click on a beat from 0 to 8 times to increment the gain of that beat as a fraction of 1 rms, where resulting rms=value/states; black is rms=0; if all beats for a row =0 (are black) then the switch for that track is turned off; double-click it to decrement it
- (effects-per-row): same as above, but per-row, ex. first column is vcf-cutoff, second is vcf-q, etc.
- ABSTRACTIONS
- $1: b8 (properties:row column)
- 8-state bang: black, red, orange, yellow, green, light-blue, blue, purple; representing a fraction of rms(gain) for the beat
- $1: b8 (properties:row column)
- GUI
- $1: [row (idx) b8] (()=a property not an abstraction)
- GUI
- $1:[KITS sample]
Credits: The included drum samples are from: https://www.musicradar.com/news/sampleradar-494-free-essential-drum-kit-samples
p.s. Though I began working on cut-copy-paste, it began to pose a Huge challenge, so backed off, in order to query the community as to 1) its utility in the current state (w/o that) and 2) just how important including it really is.
p.p.s. Please, report any inconsistencies (between the instructions as listed and what it does) and/or bugs you may find, and I will try to get an update posted as soon as enough of those have collect.
Love and Peace through sharing,
Scott
How to process non-interleaved audio with libpd_process_float?
Hi there, I'm working on a project that involves streaming audio from an AVPlayer
video player object into libpd
. For the process loop of the tap, I used PdAudioUnit
s render callback code as a guide; but I realized recently that the audio format expected by libpd is not the same as the audio coming from the tap — that is, the tap is providing two buffers of non-interleaved audio data in the incoming AudioBufferList
, whereas libpd expects interleaved samples. Does anyone know of a way I can work around this?
I think that I need to somehow create a new AudioBufferList or float buffer and interleave the samples in place; but that seems expensive to me. If anyone could give me some pointers I would greatly appreciate it!
static void tap_ProcessCallback(MTAudioProcessingTapRef tap, CMItemCount numberFrames, MTAudioProcessingTapFlags flags, AudioBufferList *bufferListInOut, CMItemCount *numberFramesOut, MTAudioProcessingTapFlags *flagsOut)
{
OSStatus status = MTAudioProcessingTapGetSourceAudio(tap, numberFrames, bufferListInOut, flagsOut, nil, numberFramesOut);
if (noErr != status) {
NSLog(@"Error: MTAudioProcessingTapGetSourceAudio: %d", (int)status);
return;
}
TapProcessorContext *context = (TapProcessorContext *)MTAudioProcessingTapGetStorage(tap);
// first, create the input and output ring buffers if they haven't been created yet
if (context->frameSize != numberFrames) {
NSLog(@"creating ring buffers with size: %ld", (long)numberFrames);
createRingBuffers((UInt32)numberFrames, context);
}
//adapted from PdAudioUnit.m
float *buffer = (float *)bufferListInOut->mBuffers[0].mData;
if (context->inputRingBuffer || context->outputRingBuffer) {
// output buffer info from ioData
UInt32 outputBufferSize = bufferListInOut->mBuffers[0].mDataByteSize; // * 2 solved faint avplayer issue
UInt32 outputFrames = (UInt32)numberFrames;
// UInt32 outputChannels = bufferListInOut->mBuffers[0].mNumberChannels;
// input buffer info from ioData *after* rendering input samples
UInt32 inputBufferSize = outputBufferSize;
UInt32 inputFrames = (UInt32)numberFrames;
UInt32 framesAvailable = (UInt32)rb_available_to_read(context->inputRingBuffer) / context->inputFrameSize;
//render input samples
while (inputFrames + framesAvailable < outputFrames) {
// pad input buffer to make sure we have enough blocks to fill auBuffer,
// this should hopefully only happen when the audio unit is started
rb_write_value_to_buffer(context->inputRingBuffer, 0, context->inputBlockSize);
framesAvailable += context->blockFrames;
}
rb_write_to_buffer(context->inputRingBuffer, 1, buffer, inputBufferSize);
// input ring buffer -> context -> output ring buffer
char *copy = (char *)buffer;
while (rb_available_to_read(context->outputRingBuffer) < outputBufferSize) {
rb_read_from_buffer(context->inputRingBuffer, copy, context->inputBlockSize);
[PdBase processFloatWithInputBuffer:(float *)copy outputBuffer:(float *)copy ticks:1];
rb_write_to_buffer(context->outputRingBuffer, 1, copy, context->outputBlockSize);
}
// output ring buffer -> audio unit
rb_read_from_buffer(context->outputRingBuffer, (char *)buffer, outputBufferSize);
}
}
Higher sampling rates and such
@raynovich Reading the help file I think it says that the header is written according to the -rate flag..... useful..? I don't think so.
Pd only uses the header to identify the file format..... it cannot adjust its sample-rate like a media player app to play files at the correct speed.
You will need to actually sample the audio at 176400 before writing the file.
So for the audio to be sampled at 176400 you will have to set that rate for Pd in the Media Audio settings tab..... so that the Pd audio rate is 176400 when you record...... if your soundcard can do it without resampling (you could well be stuck with 192K and 48K as your sample rates for this project).
Then reset Pd to a sample-rate of 44100 and the file will play back 4x slower.
If you want to do it all on the fly you will need to [block~ something 1 0.25] your synthesis in a sub-patch..... while still running Pd at 176400. But you might run into problems re-blocking for [dac~].... Not sure without trying.
Or run 2 separate instances of Pd.
One for recording @176400 and one for playback @44100..
But you will need separate sound cards for each instance so they can be set to different clocks.
I think [pd~] cannot run at a different sample-rate to its parent....... so not useful for this.
David.
Crackled Audio from PD on Raspberry Pi 4
I'm running a Raspberry Pi 4 with "Raspberry Pi OS (32-bit) Lite [August 2020 / 2020-08-20 / Kernel 5.4]" headless and the latest version of Purr-Data, set up the Raspberry using this guide , did the Alsa no audio (glitch) issue Pi 4
fix to get audio working through the 3.5 mm jack.
I'm interfacing the Raspberry Pi through the macOS terminal and with VNC Viewer through ethernet.
I get the following error as soon a starting Purr-Data,
error: audio I/O stuck... closing audio
I open up a patch and turn off and turn on the DSP signals and get the following error
error: audio I/O stuck... closing audio error: audio I/O dropout
Even though if I play sample .wav or bang a sinewave, the audio does get played but it gets glitchy as in the audio sound is crackled.
has anyone experienced it before? any knowledge on how to overcome it?
[bang~] bangs before the end of a dsp block at startup
@Nicolas-Danet OK, I think I get it. 1024 samples have "passed" (according to the phasor~ counter) inside the reblocked subpatch because sample processing lurches forward 1024 samples once every 16 64 sample blocks processed by the enclosing patch. My error is in thinking that sample counters should all progress at the same rate, like two different wall clocks would. When dsp processing starts, PD arranges all subpatches regardless of blocking to immediately start generating audio if necessary, so in the case of a 1024 sample reblocking, it just fills the first 960 samples with 0's so it can start outputting them. But it has to wait for the first 64 real samples before it has a complete 1024 vector to process.
RE the array, you can force the drawing by either clicking on it somewhere (and ignoring the point you just created), or by just leaving the subpatch closed and opening it when you want to take a look. There is also list view, which is the only way I knew that the discontinuities were on 64 sample boundaries. So it's less the array GUI element that I'm concerned with, and more the behavior of [tabsend~]. [tabreceive~] is used to implement things like Hann windows, so it has to enforce a 1-1 ordered correspondence between the source table and the current vector. I assume that [tabsend~] makes similar guarantees, but I was wondering if the switch~ was messing things up. The message to turn on dsp can come between any 64 sample block, could that be related to the timing of the discontinuity I'm seeing? When dsp is off, does PD stop accumulating the 1024 block for the subpatch? The discontinuity goes away when I declare [switch~ 1024 16 1], and it also causes the phasor~ counter to report approx 64 (because phasor~ is configured in cycles per second and so has to adjust to the current blocking, overlap, and oversampling). <BS in last sentence corrected/>
[writesf~] problem
A couple of illustrations.
Let's say we want a sine wave covering 16.5 samples. To illustrate, I used SuperCollider to put two sine wave cycles into 33 samples.
The second cycle begins when the wave crosses the 0 line in the middle.
This is between samples.
So, the second cycle must be represented by sample values that are different from the sample values for the first cycle.
That is, it is possible to have that zero crossing between samples -- but the sampling process produces different values.
Let's look at it a different way: blue samples = one sine wave cycle covering 33 samples; green samples = 2 cycles in 33 samples.
If we start counting samples at 0:
- Blue 0 = Green 0.
- Blue 2 = Green 1.
- Blue 4 = Green 2. etc.
That is: read through the blue samples at double speed, and you get the 16.5 wavelength. (This is exactly what David said.)
What about the second cycle starting at 16.5?
- Blue 1 = Green 17.
- Blue 3 = Green 18. etc.
These are the sample values that were skipped the first time.
So, Green 17 (the first concrete sample value after the second cycle begins) is the value in between Green 0 and Green 1. Green 18 is in between Green 1 and Green 2.
This is interpolation.
Interpolation is the mathematically correct way to represent fractional cycles in a sampled signal.
You can try to say that this "isn't the real problem," but... this is the problem, and interpolation is the solution.
hjh
[writesf~] problem
Hi
It is not easy for me to explain why I need maximum precision, either because of the complexity that would be explained to me and because my English is not entirely good. Although if I can try to explain a simple example (although it is far from the real purpose)
Suppose I have 2 audio samples. The first sample lasts exactly 1000ms (44100 samples) and I loop it every 1000ms.
If I had another exactly 125ms sample and looped it back at its exact time (125ms) alongside the first 1000ms sample, the beat would be perfectly in sync since it's the exact eighth part of 1000.
On the other hand, if I can only get a sample of 5512 samples (124.988..ms) and I loop it along with the 1000ms sample, as time progresses and the 124.988 sample is repeated more times ... ms, the desynchronization of time will increase ... (rhythm)
I know you can tell me that I can solve the "desynchronization" by repeating the sample every exact 125ms, but I have already said that this is just a simple example to try to explain and does not address the real problem.
As I have understood from your explanations, that sometimes it will be impossible for me to record samples to the exact duration that you want, but I can reproduce them within Pd exactly with the desired duration using the examples that you have given me. What invites me to think about the idea of not using any other means than Pd to get closer to my purpose, even if it takes more time and effort at first; But it is what I will do ..
Thank you
A greeting!!