Apologies if this is a distraction. The soundfiler object is clearly fundamental to digital music. I think it needs a makeover. I'm willing to help, but it's been getting particularly difficult and I think, unnecessarily complicated to create patches that automatically load a folder of sound files which may be mono or stereo (or even quad?).Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I prod you for a feature, and I probably have as many of these cattle prod moments hitting me from behind as I work on my patches. Cheers,Bisous,Ed
_-_-_-_-_-_-_-^-_-_-_-_-_-_-_
For Lone Shark releases, Pure Data software and published Research, go to http://sharktracks.co.uk
Ed Kelly
I couldn't agree more
by the way, I just released a cyclone update and it has an abstraction that I made which clones max's buffer~ and it has about 90% of its features. One that is missing is just something like you described, which is being able to know how many channels are there in the file and upload it accordingly with that many channels.
I even have more requests I wanted to add, which would be also giving the sample rate of the file.
Those two informations would make [soundfiler] really more powerful
cheers
2017-02-21 8:01 GMT-03:00 Ed Kelly via Pd-list pd-list@lists.iem.at:
Apologies if this is a distraction.
The soundfiler object is clearly fundamental to digital music. I think it needs a makeover. I'm willing to help, but it's been getting particularly difficult and I think, unnecessarily complicated to create patches that automatically load a folder of sound files which may be mono or stereo (or even quad?). Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I prod you for a feature, and I probably have as many of these cattle prod moments hitting me from behind as I work on my patches. Cheers, Bisous, Ed
_-_-_-_-_-_-_-^-_-_-_-_-_-_-_
For *Lone Shark *releases, *Pure Data *software and published *Research*, go to http://sharktracks.co.uk
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
On Die, 2017-02-21 at 11:01 +0000, Ed Kelly via Pd-list wrote:
Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I, too, think that [soundfiler] should output some sound file properties instead using them only internally. It would be good to be able to make patches where the patch creator doesn't need to know beforehand what exact formats are going to be opened by the patch user.
I'd like to know the following properties (in descending order of necessity): * number of channels * sample rate * bit depth
There are at least two externals, that provide this info: ext13's [wavinfo] and [soundfile_info] from iemlib. In my experience, the former doesn't read correctly all wav files that are read by other programs or by Pd, I believe it assumes a certain layout instead of truly parsing the header. [soundfile_info] seems the better choice and is able to read all files that are read by [readsf~]/[soundfiler], from what I can tell.
Roman
[soundfile_info] seems the better choice and
is able to read all files that are read by [readsf~]/[soundfiler], from
what I can tell.
In the past I found discrepancies on *sound file length*:
[soundfiler] != [sounfile_info] [soundfiler] == soundforge
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Roman Haefeli reduzent@gmail.com Sent: Wednesday, February 22, 2017 8:19 AM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler features
On Die, 2017-02-21 at 11:01 +0000, Ed Kelly via Pd-list wrote:
Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I, too, think that [soundfiler] should output some sound file properties instead using them only internally. It would be good to be able to make patches where the patch creator doesn't need to know beforehand what exact formats are going to be opened by the patch user.
I'd like to know the following properties (in descending order of necessity):
- number of channels
- sample rate
- bit depth
There are at least two externals, that provide this info: ext13's [wavinfo] and [soundfile_info] from iemlib. In my experience, the former doesn't read correctly all wav files that are read by other programs or by Pd, I believe it assumes a certain layout instead of truly parsing the header. [soundfile_info] seems the better choice and is able to read all files that are read by [readsf~]/[soundfiler], from what I can tell.
Roman
So (donc) What are uniform parameters of a soundfile? Only these are necessary to enhance soundfiler.
Channels is primary - an audio file can be any number of channels, but the soundfiler object needs to know in advance how many arrays to write to. This is non-negotiable i.e. an absolute fact.
Sample rate is secondary, and any file recorded at a particular sample rate can be played back at any other rate, but it would be nice to know this, but it is negotiable within the patch.
Bit rate - perhaps for saving this might be useful, although since saving is a generated process rather than a parameter specified within the header of a file (discuss), it is probably of little importance. The soundfiler object can already read 16, 24 and 32 bit files, and I can't see a future for 64 bit audio (although electronics manufacturers will certainly try to sell this in the future, despite the fact that most DA conversions are Sigma-Delta making bit-depth more-or-less irrelevant).
Thoughts?Ed _-_-_-_-_-_-_-^-_-_-_-_-_-_-_
For Lone Shark releases, Pure Data software and published Research, go to http://sharktracks.co.uk
On Wednesday, 22 February 2017, 12:09, Lucas Cordiviola <lucarda27@hotmail.com> wrote:
#yiv3468639400 #yiv3468639400 -- P {margin-top:0;margin-bottom:0;}#yiv3468639400
[soundfile_info] seems the better choice andis able to read all files that are read by [readsf~]/[soundfiler], fromwhat I can tell.
In the past I found discrepancies on *sound file length*: [soundfiler] != [sounfile_info] [soundfiler] == soundforge
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Roman Haefeli reduzent@gmail.com Sent: Wednesday, February 22, 2017 8:19 AM To: pd-list@lists.iem.at Subject: Re: [PD] soundfiler features On Die, 2017-02-21 at 11:01 +0000, Ed Kelly via Pd-list wrote:
Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I, too, think that [soundfiler] should output some sound file properties instead using them only internally. It would be good to be able to make patches where the patch creator doesn't need to know beforehand what exact formats are going to be opened by the patch user.
I'd like to know the following properties (in descending order of necessity): * number of channels * sample rate * bit depth
There are at least two externals, that provide this info: ext13's [wavinfo] and [soundfile_info] from iemlib. In my experience, the former doesn't read correctly all wav files that are read by other programs or by Pd, I believe it assumes a certain layout instead of truly parsing the header. [soundfile_info] seems the better choice and is able to read all files that are read by [readsf~]/[soundfiler], from what I can tell.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2017-02-22 13:33 GMT-03:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2017-02-22 17:11, Alexandre Torres Porres wrote:
good, bit depth is important too, I could add file extension to the list
whatever features you want to extract, i suggest to not use a specific outlet for each, but instead add a 2 info-outlet that outputs key/value pairs that are easily routable.
+1
isn't the file-extension input data?
yes, still find it useful, specially for input from openpanel, but I see might be pushing here...
2017-02-22 9:22 GMT-03:00 Ed Kelly via Pd-list pd-list@lists.iem.at:
- Sample rate is secondary, and any file recorded at a particular sample
rate can be played back at any other rate, but it would be nice to know this, but it is negotiable within the patch.
I don't see it as "negotiable", it's quite important. Yes they can be played at any other sample rate, but that changes de reading speed/pitch, and what if you wanna have control over that? Say you opened a file recorded at 96Khz and you wanna play it at the sample rate that Pd is running which is 44.1Khz. For now, you basically need to know this information before hand.
- Bit rate - perhaps for saving this might be useful
That's the usefulness I saw in it, and would also help in improving my buffer~ abstraction.
Thoughts?
Ed
I, for one, would like to negotiate the inclusion of as many information as possible, as you may notice, but I know not everyone feels like that and this is quite unlikely. I could be reasonably satisfied with channels and SR info, I'll surely have a smile on my face when that happens...
and since we are talking about externals doing that job, cyclone could have an [info~] object that spits out a LOT of information about a sample... the problem is that it's tied to [buffer~]
https://docs.cycling74.com/max7/maxobject/info~
cheers
2017-02-22 5:19 GMT-03:00 Roman Haefeli reduzent@gmail.com:
I'd like to know the following properties (in descending order of necessity):
- number of channels
- sample rate
- bit depth
good, bit depth is important too, I could add file extension to the list
On 2017-02-22 17:11, Alexandre Torres Porres wrote:
good, bit depth is important too, I could add file extension to the list
isn't the file-extension input data?
whatever features you want to extract, i suggest to not use a specific outlet for each, but instead add a 2 info-outlet that outputs key/value pairs that are easily routable. then you can add more extracted features later without breaking anything (and ending up with 27 outlets).
as in: [channels 2, filename foo.wav, date 2017-02-22, answer 42(
dfams IOhannes
Yep. Actually, I would like [soundfiler] to give the option of outputting this info without actually loading the file into arrays (sometimes you need this info before you stream a random file from disk). Could be an option in readsf~, too, but if soundfiler already does it....
On Tue, Feb 21, 2017 at 6:01 AM, Ed Kelly via Pd-list pd-list@lists.iem.at wrote:
Apologies if this is a distraction.
The soundfiler object is clearly fundamental to digital music. I think it needs a makeover. I'm willing to help, but it's been getting particularly difficult and I think, unnecessarily complicated to create patches that automatically load a folder of sound files which may be mono or stereo (or even quad?). Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I prod you for a feature, and I probably have as many of these cattle prod moments hitting me from behind as I work on my patches. Cheers, Bisous, Ed
_-_-_-_-_-_-_-^-_-_-_-_-_-_-_
For *Lone Shark *releases, *Pure Data *software and published *Research*, go to http://sharktracks.co.uk
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
i'm sure you guys have the riff wave format, looked last night and my riff wave header parsing thingy is from the 16 bit era where options are chunks and ch specs all said mono or stereo and sample rates were all listed as <=44100 will grab my code and post if yall want for historical purposes. and to hijack this thread its kinda on topic with another thread about loading up a bunch of samplers from a folder full of samples well after 20+ years of collecting drum samples and loops i finally indexed my entire collection and organized into what i think is the bees knees except i have allready thought of a better way because it's still quite a job to cycle through thousands of options lol here is part of my indexing complications. ##### #!/bin/bash
ls -R --ignore=*.* -1 | while read -r FILE do FILE2=$(echo $FILE | tr -d ' ') if test -e "$FILE2" then echo "Warning: file already exists: " else echo mv -v "$FILE" "$FILE2" fi done
ls -R --hide=*.txt --hide=*.TXT --hide=*.txt~ --hide=*.frm --hide=*.pk --hide=*.PK --hide=*.diz --hide=*.drp --hide=*.DIZ --hide=*.TXT --hide=*.exe --hide=*.1st --hide=*.sh --hide=*.drums --hide=*.gif --hide=*.jpg --hide=*.html --hide=*.LOG --hide=*.trk -1 | while read -r FILE3 do FILE4=$(echo $FILE3 | tr -d ' ') if test -e "$FILE4" then echo "Warning: file already exists: " else echo mv -v "$FILE3" "$FILE4" fi done ### getting rid of the spacey filenames then there was the complication that some collections of waves are their own nested collection themselves al self similarity of the entire collection fractalized in the most natural organization, self similarity does not always mean self organized and self indexable so.. instead of the tree nodal list type construct, instead a flat out list of all the end points , the fruits of the temporal chatter bits tree fictitious example : imagine a folder called bngboz which has in it subfolders like acprc, thudz, lemonroger, rarland7enty7, rarland8ie8, etc.. and lo and behold a listing of , thudz actually reveals the bangbit .wav fruit however rarland7enty7 and rarland88ie8 has no such .wav fruit till you crawls off their branches labeled something like bass, snare, toms, cymbols so for the main index you end up with a flat list of only the fruit containing endpoints something like
bngboz/thudz bngboz/lemonroger bngboz/rarland7enty7/bass bngboz/rarland7enty7/snare bngboz/rarland7enty7/tom bngboz/rarland7enty7/cymbols bngboz/rarland8ie8/bass bngboz/rarland8ie8/snare bngboz/rarland8ie8/tom bngboz/rarland8ie8cymbols
as entries in the main index instead of just plain bngboz
then you can get to every one of your samples with only 2 moves scrolling through the main index , then scrolling through the samples till you find that late sound you were always looking 4
attached are pics of an interface which might not be the best way to go am interested how Ed Kelly deals with this opening up all the samples in the end branches so.. can we change the topic to microtonal xenharmonic soundfonts now? talk about lessons in relative paths perhaps i ought to relocate some patches as the mixer/recorder of WAVEFILES is located in the sequencer(burningship) folder which has the WAVE drumloop sampler in it as well as the "pd/congas" patch which itself is in ../polysynth/kicksnrctrl which references back to ../burningship/sampleselect.pd as well as other relatively zigzagishnesnoused pathz of wonder party like it's 1999 look what i found, i thought these waves were lost http://billystiltner.bandcamp.com/album/nanobot-velocity-factor-mm-mixes
On Thu, Feb 23, 2017 at 9:21 PM, Matt Barber brbrofsvl@gmail.com wrote:
Yep. Actually, I would like [soundfiler] to give the option of outputting this info without actually loading the file into arrays (sometimes you need this info before you stream a random file from disk). Could be an option in readsf~, too, but if soundfiler already does it....
On Tue, Feb 21, 2017 at 6:01 AM, Ed Kelly via Pd-list < pd-list@lists.iem.at> wrote:
Apologies if this is a distraction.
The soundfiler object is clearly fundamental to digital music. I think it needs a makeover. I'm willing to help, but it's been getting particularly difficult and I think, unnecessarily complicated to create patches that automatically load a folder of sound files which may be mono or stereo (or even quad?). Since this information is contained within the header of each file (although it's a pain with the different formats), would it not be sensible to have a second outlet in soundfiler that delivers the number of channels, before the number of samples in the file is delivered from the left outlet? Perhaps also other info, but what would be relevant to a patch? I think channels is a necessary piece of information.
I prod you for a feature, and I probably have as many of these cattle prod moments hitting me from behind as I work on my patches. Cheers, Bisous, Ed
_-_-_-_-_-_-_-^-_-_-_-_-_-_-_
For *Lone Shark *releases, *Pure Data *software and published *Research*, go to http://sharktracks.co.uk
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
-
Alexandre Torres Porres -
Billy Stiltner -
Ed Kelly -
IOhannes m zmoelnig -
Lucas Cordiviola -
Matt Barber -
Roman Haefeli