i thought it’d be cool to also be able to randomize notes based on different scales for coming up with neat melodies, kinda pseudo-arpeggio, just not using the effect column. hence random notes. anyways, i could have done the algorithm (maybe), but you guys already got the randomize stuff happening so you could implement it better. these are only a few of many many scales, they’re are just the ones i use the most. i hope you guys find the idea useful. I made a note generator based on a LOT of scales in max/msp that randomized notes/chords/how many times the notes/chords played etc. it then outputted them as a midi file to load into cubase. i found this great for melodies.
I hope you guys can somehow use the same idea, like just add a randomize by scale option maybe? implement it to randomize the notes based on a randomized scale, or a selected scale. Complete randomization, how many times the note is played, chords, whatever you can think of. PURE MELODIC IDM FUN. also i’d randomize all the above but also randomize the octaves of the scales… possibly 1 octave lower and 1 octave higher than middle c, along with the octave of middle c. or whatever you really want to do.
also it should go without saying, but these are only root c. obviously different roots could be used, the simplest of music theory. maybe it could also randomize a root to use, and obviously each octave generated would use the same root, but possibly still different note variations.
I will update the TROTCH page later this evening. Feedback is appreciated. Thanks to P7 who found a bug that we were able to resolve via IRC. I will look into these other randomize algorithms, but not today. I am not very well versed in music theory, but if I understand it programmatically I’m pretty sure I can do it. Although, someone else probably could too. The more scripts the merrier!
i think everyone with coding experience should get involved. Along with these ideas, there’s probably tons more to be done. I’m sure it wouldn’t be hard to make a “instaglitch” type script that manipulates sample offsets and random reverses, etc,etc,etc. (that’s for you jbl, no more instajungle ) by manipulating the sample. i might try a few things in c# with the libraries shortly, if i get motivated enough.
Btw, has anyone considered using the JUCE library in cpp for this stuff? I’ve been using it for a while and since it wasn’t important i overlooked it, but JUCE has it’s own XML core classes.
“XmlDocument and XmlElement - for parsing XML into a tree of XmlElements, which can be easily manipulated and turned back into a text document. The XmlElement class is actually quite a powerful object for storing data structures in its own right, even if it doesn’t need to be externalise”
I’ve decided to release a next version to the public. It’s still not feature complete though. This version includes also the ogg encoder script written by conner_bw, so you can finally compress your XRNS files very easy and without all the usual steps like described in the In:Depth article. Please report any problems you might have here.
Edit: Please don’t extract this version into the same folder like the old one. Delete it first! I’ve modified some folder names.
This is the kind of stuff we need before this GUI, the scripts can make it to the front page. Please paste the console error. (Click the upper left corner -> Edit -> Mark -> [select] -> [enter] -> -> Reply to this thread -> [ctrl-v]). There are no mysql calls in any of my scripts so I’m not too sure what that’s about.
Also, there are a few more GUI modifications in the pipework. This is probably not the final version. Testing and suggestions are needed.
I think it’s maybe best to wait a little bit, until the first final version is ready, shouldn’t take long anymore.
This should not happen. I’m directly hardcalling the PHP interpreter from the package and pass the -n switch to it, to suppress any php.ini parsing. I’ll have a look at it tomorrow, maybe i’ll find the cause of it.
I’ve just tried to compress a xrns of mine to an xrns with oggs using your utility on quality level 10, and the outcome features a lot of glitch clipped .oggs
It is strange, some samples are perfecly converted, some are not. Ahh, now that I look at the original xrns again…the samples are all 44100 khz 24 bit! So can I conclude ogg conversion from 24 bit samples is not yet supported?
Also, the utility created a folder inside the folder where I opened the to be converted xrns (created folder: xrns_ogg_01834c7faccf38bfb47e59edb2230161_Track01 )
Would be nice if this empty folder could get deleted after conversion.
And a pop-up window telling me the conversion is done / finished would be nice aswell
The conversion is done by an executable known as ‘oggenc’, doing oggenc -h outputs the following:
OggEnc input files must currently be 24, 16, or 8 bit PCM WAV, AIFF, or AIFF/C
files, 32 bit IEEE floating point WAV, and optionally FLAC or Ogg FLAC. Files
may be mono or stereo (or more channels) and any sample rate.
Alternatively, the --raw option may be used to use a raw PCM data file, which
must be 16 bit stereo little-endian PCM (‘headerless wav’), unless additional
parameters for raw mode are specified.
It should not fail in conversion. The script basically just runs a loop on all the files passing it on to oggenc. If it’s failing then the bug needs to be reported to xiph.org. But, before doing that I’d like to see what is going on with your file… Can I also get a copy? Does the console output anything weird?
This is a mystery, this doesn’t happen on OS X, and doesn’t happen on all windows installations… It’s a permission issue that I have spent days trying to figure out, but have not been able to.
For now, click “show console” before launching a script, you’ll get a lot of info flying by that describes what is going on.
Hey, everything works perfect! It seems like it takes longer to convert now, but no glitches or clipping (and the folders are gone aswel .
Btw I like the randomisation, can spark up a whole new direction on forgotten tracks. Maybe for the future it would be cool to be able to control the amount of randomisation in each track.
Flac’s are now being decoded/converted into wav files by another command line app before being passed to oggenc, so you perception of it being longer is right on. There’s two steps instead of one now. I sent a bug report via email to xiph.org, your flac files (which i got from beatslaughter) were being converted into corrupted interpretations.
) by manipulating the sample. i might try a few things in c# with the libraries shortly, if i get motivated enough.
