(-_-) (-_-) (-_-) (-_-) (-_-)

i figured since bytebeat is a really new format and no other format on botb is like it, it would be good to (semi-organically) make a collection of cool tips and trix on it so we can learn more stuff about it (and i haven't found good tutorials on it so i've just semi-blindly been messing around with it)

post cool bytebeat stuff and tricks u find on this thread, let's get a collection going ; )))))

also if you find something cool and you want someone to explain how it works do that as well...

(-_-) (-_-) (-_-) (-_-) (-_-)

okay so for my first cool trix (super n00b trick) if u do

(other poop) | t >> x

u get a cool oontz beat thinginging to all ur noise....changing x gives u a different tempo (t >> 4 seems the most oontzy)

yeah i used that one p extensively in mine

t*2&t>>8 gives you a Sierpinski harmony

So apparently you can use functions... because I was bored, here's the first steps towards a proper tracker kind of feel to it (needs bytebeat not floatbeat):


sing();
function sing(){
var n = {c2:65.41,cs2:69.30,d2:73.42,ds2:77.78,e2:82.41,f2:87.31,fs2:92.50,g2:98,gs2:103.83,a2:110,as2:116.54,b2:123.47,c3:130.81,cs3:138.59,d3:146.83,ds3:155.56,e3:164.81,f3:174.61,fs3:185,g3:196,gs3:207.65,a3:220,as3:233.08,b3:246.94,c4:261.63,cs4:277.18,d4:293.66,ds4:311.13,e4:329.63,f4:349.23,fs4:369.99,g4:392,gs4:415.30,a4:440,as4:466.16,b4:493.88,c5:523.23};
ch1 = [n.a3,n.b3,n.c4,n.f4,n.e4,n.c4,n.b3,n.f4,n.e4,n.a4,n.gs4,n.b4,n.a4,n.e4,n.a3];
ch2 = [n.a2,0,n.e3,0,n.a3,0,n.e3,n.gs3,n.a3,0,n.e3,0,n.a2,n.e3,n.a2];
var rhythm = 2000;
var pos = (t-t%rhythm)/rhythm;
return sine(ch1[pos])+sine(ch2[pos]);
}
function sine(desired){
return ((sin(t*desired/1300))+1)*50;
}

Next step will be to have a tri channel, a saw channel, a sine channel, with customisable note lengths, and then events, and then suddenly we have a new tracker format!

So why exactly is "t" outputting a saw wave?
I'd have a much easier time understanding how things work if I can relate the code to math and the math to continuous functions and continuous functions to whatever format of PCM is output.

it's doing something like this
char t;
for(t = 0;;t++)
{
// t equation poop crap
}

or....

waveposition = // t equation poop crap //

if u do waveposition = t, it will increase by 1 per time. a character only goes up to 255, it hard wraps back to 0, producing a saw wave.

ah, so every single entry could be thought of as "y = (expression) % 255" with respect to time. Gotcha.

Now to learn C

if u want to centre the waveform, just add 128

what's the actual rule on ByteBeat? can i write any C program that emits a unsigned 8 bit 48 kHz stream? or does it have to be a single expression?

use a single ';' in your loop that increments 't' if you're writing it in C (or any other similar programming language)

http://www.royvanrijn.com/blog/2011/12/bytebeat-algorithmic-symphonies/

otherwise you could just make an mp3 decoder that outputs 8bit audio and call that bytebeat d:

I kinda feel that using more than one expression, variable, and/or having subroutines is cheating... (#DEFINE is okay tho in my book)

however I have no idea on the official rules of the format.

well if you're doing it in javascript you can do like

(function(){
...
})();

as your "expression"

Wouldn't that be considered a subroutine? Inline routine? eh, you know what I mean! The expression inside would probably still have multiple semicolons anyways so that probably would still break the my rules d:

you don't even need to make an mp3 decoder, just include the raw PCM data as a string literal and index it with t, like "\x01\x02\x03..."[t]

i kind of want a word-of-god call on this

(((t%size_of_pcm)==0)*27)+
(((t%size_of_pcm)==1)*21)+
(((t%size_of_pcm)==2)*37)+
...
(((t%size_of_pcm)==n)*sample)

indexless ............

I would bet that the call would be on the voters
if you think it's low-effort, don't vote it high d:

While I know people have used functions here and there in bytebeat since it's inception, I had no idea they could become such a game changer. I believe that bytebeat came about as a very simple idea of running algorithms against time. I, personally, feel that brute forcing this system to act in ways outside of that original vision kills the sport of this new format.

It's also not fair to change the rules of engagement mid-battle. BotBrs have already submitted entries that utilize functions in a tracker-esque way. I don't think anyone should suffer simply because the rules were not or ill defined.

These are my gut feelings on the issue. Maybe a general rule of thumb could be to use only one function. Defining constants sounds totally fair too. I'm not ready to make any hard or fast call here.

Man, I have no idea. There's some cool stuff coming from functions.

for this one competition i'd let it slide by but for the next one i would personally unallow functions
bytebeat is basically something inside a for loop so it doesnt make sense to make functions inside of a for loop, afaik it wouldnt work at all
maybe, we should have some programming related format! for music, and for other stuff even! but thats subject for another thread i think

Csound comes to mind

csound format would be super neat

Maybe this is a good idea to make a major sound programming compo with csound, puredata, supercollider, bytebeat and other cool formats.

I'm strongly against disallowing functions or more than a set number of variables. Functions are very useful to write comprehensible and readable bytebeat tunes that others can learn from.

It's much more sensible when every instance of _{((((2147483648 >>> (floor((t/4096)%128))) & 0) != 0 ) ) * ( ((t/4096)%128);} is replaced with a simple variable;

Also, people can use a macro expander to expand functions or variables (or just code their own... (this would give coders even more advantage)) The end result will be exactly the same, except much less readable.

Of course embedding PCM or an excessive amount of tracker data into a bytebeat tune is something that should be prevented. :P

I think a file size limitation would by far be the best way to go about this....

Hehhhhhh it was 5am when I posted that. I could have went through and removed a lot of lines that actually don't do anything but it was working and that's all I cared about at that point.

Later on I'm going to try to write up a little about what the code is actually doing so people can see how it's doing what it's doing.

If people are looking at bytebeat as more of a music programming format rather than a single expression of code (which is what I thought of it was based on the few examples I had seen of it when I was first introduced to it), then having functions sounds just fine. I remember a while back a lot of people were hoping for a programming format to be introduced since a good number of Botbrs have some experience with code, and this would probably fill that hole if people want to use functions and stuff.

As for filesize limitations, there could maybe be multiple formats like how there is mod8k mod16k etc (although that might get too cumbersome with too many formats) Maybe two (or three) instead? One relatively small, and the other fairly large? I don't have enough references to what reasonable sizes of them would be... Or maybe there's a universal filesize limitation and there's two bytebeat format types: One with functions and all that extra stuff, and one that's just a single expression.

I dunno, bytebeat is a new format with a lot you can do with it... and banning what could be a large chunk of it would probably be bad... but limitations are the backbone to a lot of battles here, but usually those limitations are hardware/bitpack based.

All this talk about it is good.

I think you've swayed my initial view Sylveon

hehe sylveon my reasoning against functions is that you cannot put functions inside of a for loop and bytebeat is basically
main(t){ for(t=0;;t++)putchar(
*your stuff*
);}
as for variables i dont see any problem, for a similar reason
and well... as for filesize limitation, i dont think its necessary either, although the purpose of bytebeat at first was like a single line that could make impressive sounds and not like and not like a huge thing (which is also impressive!) but it WOULD work so why not


for short, everything that works inside of a for loop is okay imo.

"Also, people can use a macro expander to expand functions or variables (or just code their own... (this would give coders even more advantage)) The end result will be exactly the same, except much less readable."

This is actually kind of my reasoning why I think functions *shouldn't* be allowed. Bytebeat is already powerful enough without them (I mean hell, look at Savestate's entry, he made a melody without using functions once). Allowing functions almost seems *too* easy. :P

I also agree with raphael's reasoning that they wouldn't work inside of a for loop (which was how bytebeat originally started). Plus, functions seem to only be supported by the greggman generator, and ideally the entry should work on multiple different generators.

IMO character limits are the way to go to introduce different subformats of bytebeat. Only so much basic functionhacking you can do to with a short character space, but it'd still allow for insane creativity without explicitly being all "you can't do Thing X."

It'd be like code golf with music. :P

"Plus, functions seem to only be supported by the greggman generator, and ideally the entry should work on multiple different generators."

hmmmmmm you do have a point there.

Maybe in the future, when bytebeat battles are hosted, the bitpack should determine whether or not non-portable-to-c code should be allowed... but then again, that's kinda only making an exception for the html5 player.

gah I'm so torn!

right, the way bytebeat started, you could only use a single valid C expression of t, but this is something that the various web-based implementations can't reasonably enforce, and there are entries that don't work that way

As someone who understands audio but is just starting out programming, I gotta say that bytebeat has been unbelievably educational. Being able to get instant feedback as to what your program is doing on-the-fly is brilliant for me.

Viznut (the creator of bytebeat himself) has a few bytebeat programs featured on his site that only work in JS. Programs that use functions and variables. I also noticed there are some C bytebeats that define one or more extra variables in a single expression (which is possible in K&R C, but not in ANSI C which most C compilers use)

https://www.youtube.com/watch?v=tCRPUv8V22o&t=313s
http://pelulamu.net/countercomplex/music_formula_collection.txt

The HTML5 editor is by far the most convenient and n00b-friendly to work in, and it's linked in the lyceum. It's pretty much already our official bytebeat player at this point. I don't think it's fair to require n00bs to detect C portability issues with their tune, especially if they don't have a K&R C compiler and a UNIX-like OS.

Considering how different bytebeat players work differently and aren't 100% compatible with each other, I think it's best to just require people to specify what player their song works with.

if you want to create a 12.5% pulse wave then use this script in your bytebeat: u= note thing
sin(t/u)*1.1

also you can sorta make a tracker without functions!
v="notes"
[t>>length of notes&how many notes there are minus 1],w=(t*v)

I made a Bytebeat guide

I decided to make a guide because I didnt find a guide that i liked a lot, I put a lot of time and effort on this guide, so please take a look at it, also in the guide I left a part for things that are left to do or understand of bytebeat, I also recomend that if you consider yourself a bytebeat expert, you make a guide of your own, with all the advance learnings. (I'm not a native english speaker, so please forgive my grammar errors) the link https://drive.google.com/file/d/1uxgDR60iwMvvoN96s_OGl5nz5KEHDKN-/view?usp=sharing