Head-Fi.org › Forums › Misc.-Category Forums › Members' Lounge (General Discussion) › The diary entries of a little girl in her 30s! ~ Part 2
New Posts  All Forums:Forum Nav:

The diary entries of a little girl in her 30s! ~ Part 2 - Page 445  

post #6661 of 21761
Quote:
Originally Posted by Vuroth View Post

Voldemort, I assume.
 

>:0 DUDE SERIOUSLY? Mind blown. Not really. But that's great to know! Well idk if it's great to know... but w/e. New fact learned!

post #6662 of 21761
Quote:
Originally Posted by Vuroth View Post

Iirc the android thread has been all abuzz about some piece of software that is letting a ton of android devices output audio to USB.  I'm not as read up as I should be, but maybe they're all supported via a software fix????

 

For any specific phone and version of Android it should require little more than installing the appropriate hardware drivers and having music software that knows how to use them. I know very little about the Android platform, so I don't know how simple or hard a problem this is to do in a universal way. It could be as trivial as gluing tab A and slot B together, or it could be as complex as requiring driver software for every possible USB configuration and every possible OS configuration on every possible phone. The reality is probably somewhere in between, since there are individual handhelds and tablets that already have (or have been hacked to provide) USB audio out.

post #6663 of 21761
Thread Starter 
Quote:
Originally Posted by MrViolin View Post

>:0 DUDE SERIOUSLY? Mind blown. Not really. But that's great to know! Well idk if it's great to know... but w/e. New fact learned!

 

It's just a theory I've seen. Not sure if I believe it, but the argument is fairly compelling in some cases. But that's not worth getting into here (let's please not get into it here...).

post #6664 of 21761

So....how 'bout them Yankees?  rolleyes.gif

post #6665 of 21761
Thread Starter 

I think my Glacier is possessed. I've had to reset it like six times so far. Whenever it charges via USB I can power it on and off just fine, however as soon as I unplug it it wont power on (even if it's charged). I have to reset it at the back using a pin, and then it turns on. Only resetting it also resets the gain settings, which are on medium, so I have to re-set the gain to low again by using a pin at the back. Then when I go to plug it back into the USB, it wont power on until I reset it yet again.

 

LOL. Oy....

post #6666 of 21761
Quote:
Originally Posted by MuppetFace View Post

 

It's just a theory I've seen. Not sure if I believe it, but the argument is fairly compelling in some cases. But that's not worth getting into here (let's please not get into it here...).

^ah alright. Will do :)

 

Ah~ the weekend has come.

post #6667 of 21761
Quote:
Originally Posted by MuppetFace View Post

I think my Glacier is possessed. I've had to reset it like six times so far. Whenever it charges via USB I can power it on and off just fine, however as soon as I unplug it it wont power on (even if it's charged). I have to reset it at the back using a pin, and then it turns on. Only resetting it also resets the gain settings, which are on medium, so I have to re-set the gain to low again by using a pin at the back. Then when I go to plug it back into the USB, it wont power on until I reset it yet again.

 

LOL. Oy....


This sounds like a product with many defects.

post #6668 of 21761
The CLAS is a good DAC but you'll be stuck carrying around a brick. If you're ok with that it'll work if not its going to be a huge nuisance. Have you messaged TTVJ about your hiss problem? I haven't kept a close eye on the Glacier thread but you're the first I've run across complaining of hiss. Maybe Todd can swap your unit for another one or maybe you'll need to ask him to lower the gain on it? With all the problems you're having with it sounds more like it may be defective.
Edited by DigitalFreak - 2/22/13 at 12:45pm
post #6669 of 21761
Warning: Nerdy nerd rant, and read if you want to learn about the importance of keeping things simple and logic. (Click to show)

 

Why on earth would anyone want to code software that makes use of temporary tables that are filled and then emptied?

 

Let's say you have a person. This person starts in a state of A, moves on to state B and then to C. They can not be in two different states at the same time, and they follow the same pattern: A->B->C. So, logically, you'd want to have a table that is called 'state', with a list of person IDs and then their states. Let's simplify this with an example (don't mind me calling person 'ID' - it's just for the purpose of showing you).

 

Example 1:

 

[State]

-----------

ID | State

-----------

1  |  A

2  |  B

3  |  C

 

Seems logic, right?

 

Now, how about creating three different tables?

 

Example 2:

 

[State_A]

---

ID

---

1

 

[State_B]

---

ID

---

2

 

[State_C]

---

ID

---

3

 

It doesn't seem TOO complicated, right? Wrong, this CAN, and probably WILL introduce some faults to your beloved system. To understand WHY this is wrong, let's look at how the database would actually transfer a person from state A to state B: First it UPDATEs State_B table with the person that is changing, then it DELETEs the same person from the State_A table. This means, that a person actually breaks the rules, and is at least at one moment in time in both State_A and State_B, something that was forbidden in accordance to our rules, right? What if we did it the other way around? We DELETE this person from State_A and then create an identical person in State_B? Well, this is in accordance to our rules, I'll give you that, however, this also means that for a moment in time this person doesn't even exist, just to have an identical copy of itself to start existing in State_B - and this breaks our rules - this person has to start in State A - remember?

 

Well, obviously we're breaking some rules, and doing some real nasty magic wizardry things to our person in Example 2. Now, humans are working with databases, and as humans we all make errors. It's ion our inevitable future that we will screw things up at least once, and this also means that we have to correct these things. So, instead of waving our magic wands and saying "Person, go from State A to State B" we start coughing and accidently tell our person to go to State C. Bummer!

 

Had we instead of using our temporary tables, used the one persistent State table, we could've easily just gone in there and UPDATEd the state of the person from whatever state the person is in, to the state the person should be in, and added some logic to our beloved little frontend that says "Sir, you can't change the state of the person to C unless he's in state B and only in the state of B. Please go back and review what you are trying to do, sir.".

 

But hey, we can still fix this! Let's wave our magic wands and tell our person to delete himself and recreate himself into State B. That'll solve the whole dilemma for us. We can go home, and feel extremely happy that we are such good wizards and that Harry Potter probably be better off staying out of our ways. Now, this wouldn't fix things if we accidently had our power off in the middle of DELETE:ing and UPDATE:ing, because, if the person does not exist in the middle of a transfer - then I'm sorry to say, unless we log our magic and backup our database, there is no way to fix it. Our person just doesn't exist anymore.

 

Now, let's complicate things a bit further: let's add about 10 more states and let's obfuscate the names of the table a bit:

 

Let's call the tables [eStaBCA], [cStaCBA] and [aSteCAB] and so on. Also, instead of IDs, let's use something even funnier, like an Autonumber (an automated incremental number) to represent the person, because that way we don't have to worry about naming him 1, 2 or 3, or Steve. Our database does it for us automagically. It's like our magic wands are saying the spells for us, and since we don't even have to know the spells anymore, it doesn't matter that everything is obfuscated.

 

Until something goes awry wrong, and that's why I'm sitting here on a friday night at 10 PM, instead of being with my family hugging my wife to sleep.

 

I'm going home.

 

Okay, obviously it would still work some added logic with having three different tables and so on. I mean, all roads lead to Rome, and this is mostly true in computer science as well. But it certainly isn't a secure way of doing things, to have a person duplicated and then the first copy of it deleted. I just wish that in 10 years, someone isn't going to have these kinds of rants about software and systems that I develop. biggrin.gif

post #6670 of 21761
Quote:
Originally Posted by MuppetFace View Post

 

 

 

Yum.

 

The only other alternative that interests me along these lines is the CEntrance HiFi M8. It includes an amp section and seems pretty powerful though, so again I'm worried about noise.

 

The colour of this HeadAmp chassis justtongue_smile.gif turned my head!

post #6671 of 21761
Quote:
Originally Posted by TwinQY View Post

@warren - would probably have half my current post count and 9th most long winded poster as a custom title if I did. Not fun.

 

Fair enough.  And of course we'd gladly have you either way.

 

Quote:
Originally Posted by Silent One View Post

But blink.gif.......we ain't vegetarian. I only went down this path of stricter disciplinary consumption for, um, ksc75smile.gifpersonal disciplinary reasons.

 

That's okay.  Good food is still good food.  The fact that it just happens to me devoid of meat is just a minor detail here.

 

Quote:
Originally Posted by Silent One View Post

On Cioppino, I can't speak to LA. But since the dish has its origins in San Francisco, I could stumble there or Monterey with you for some of the best! wink.gif

 

Hmm, that depends on whether I make it back up there before you come back.  Actually, I think I have an event in late April.  I'll check on dates and get back to you.

 

Quote:
Originally Posted by MuppetFace View Post

My Apex Glacier arrived. I'm crestfallen.

 

...

 

I'm done playing around with it

 

Yeah, I was gonna suggest just sending it back... if for no other reason than to exchange it for one that might not be defective.  However, as is often the case, I have completely missed the entire topic altogether in my absence.

 

Quote:
Originally Posted by MuppetFace View Post

 

Not sure where to go from there... Thing is, I'd also like a portable DAC of some sort given that I intend to use it with my notebook and not just my DAPs... The more I think about it, the more sense it makes to go for an external portable DAC like the CLAS -dB or Pico DAC. I'm still mulling over returning to iOS, but if I'm not mistaken the CLAS now features USB connectivity for non-iDevices. If I went that route, then I'd probably pair it up with the Pico Slim:

 

 

 

I'm actually toying with the idea of setting up a rig with an SGSIII and a Meridian Explorer.  I haven't confirmed that the Explorer is class compliant yet, but if it is Ishould be good to go.  I'll add an extra battery pack to power the Explorer, and then make a mini-USB cable that draws power from the battery pack but data from the phone.  I think the biggest hurdle is how to deal with the roly-poly-ness of the Explorer.  Straps can only do so much.

 

Quote:
Originally Posted by Kamakahah View Post

Had to catch up on 10 pages so I'm late to the fried chicken convo but are there not any Southern Californians here?
Roscoe's Chicken & Waffles.
Mind blowing deliciousness. And you can get it with purple or red to drink. Doesn't get much better.

 

I was going to mention that, but it seemed like we were limiting the discussion to chains and franchise establishments.

post #6672 of 21761
Quote:
Originally Posted by Coq de Combat View Post

Warning: Nerdy nerd rant, and read if you want to learn about the importance of keeping things simple and logic. (Click to show)

 

Why on earth would anyone want to code software that makes use of temporary tables that are filled and then emptied?

 

Let's say you have a person. This person starts in a state of A, moves on to state B and then to C. They can not be in two different states at the same time, and they follow the same pattern: A->B->C. So, logically, you'd want to have a table that is called 'state', with a list of person IDs and then their states. Let's simplify this with an example (don't mind me calling person 'ID' - it's just for the purpose of showing you).

 

Example 1:

 

[State]

-----------

ID | State

-----------

1  |  A

2  |  B

3  |  C

 

Seems logic, right?

 

Now, how about creating three different tables?

 

Example 2:

 

[State_A]

---

ID

---

1

 

[State_B]

---

ID

---

2

 

[State_C]

---

ID

---

3

 

It doesn't seem TOO complicated, right? Wrong, this CAN, and probably WILL introduce some faults to your beloved system. To understand WHY this is wrong, let's look at how the database would actually transfer a person from state A to state B: First it UPDATEs State_B table with the person that is changing, then it DELETEs the same person from the State_A table. This means, that a person actually breaks the rules, and is at least at one moment in time in both State_A and State_B, something that was forbidden in accordance to our rules, right? What if we did it the other way around? We DELETE this person from State_A and then create an identical person in State_B? Well, this is in accordance to our rules, I'll give you that, however, this also means that for a moment in time this person doesn't even exist, just to have an identical copy of itself to start existing in State_B - and this breaks our rules - this person has to start in State A - remember?

 

Well, obviously we're breaking some rules, and doing some real nasty magic wizardry things to our person in Example 2. Now, humans are working with databases, and as humans we all make errors. It's ion our inevitable future that we will screw things up at least once, and this also means that we have to correct these things. So, instead of waving our magic wands and saying "Person, go from State A to State B" we start coughing and accidently tell our person to go to State C. Bummer!

 

Had we instead of using our temporary tables, used the one persistent State table, we could've easily just gone in there and UPDATEd the state of the person from whatever state the person is in, to the state the person should be in, and added some logic to our beloved little frontend that says "Sir, you can't change the state of the person to C unless he's in state B and only in the state of B. Please go back and review what you are trying to do, sir.".

 

But hey, we can still fix this! Let's wave our magic wands and tell our person to delete himself and recreate himself into State B. That'll solve the whole dilemma for us. We can go home, and feel extremely happy that we are such good wizards and that Harry Potter probably be better off staying out of our ways. Now, this wouldn't fix things if we accidently had our power off in the middle of DELETE:ing and UPDATE:ing, because, if the person does not exist in the middle of a transfer - then I'm sorry to say, unless we log our magic and backup our database, there is no way to fix it. Our person just doesn't exist anymore.

 

Now, let's complicate things a bit further: let's add about 10 more states and let's obfuscate the names of the table a bit:

 

Let's call the tables [eStaBCA], [cStaCBA] and [aSteCAB] and so on. Also, instead of IDs, let's use something even funnier, like an Autonumber (an automated incremental number) to represent the person, because that way we don't have to worry about naming him 1, 2 or 3, or Steve. Our database does it for us automagically. It's like our magic wands are saying the spells for us, and since we don't even have to know the spells anymore, it doesn't matter that everything is obfuscated.

 

Until something goes awry wrong, and that's why I'm sitting here on a friday night at 10 PM, instead of being with my family hugging my wife to sleep.

 

 

Wait, I'm still trying to wrap my head around why someone would even want to do the above?  Things don't code themselves right?  So at some point in time, some bloke was attempting to accomplish something, and I can't figure out what that might be given the method used.

post #6673 of 21761
Quote:

Originally Posted by Coq de Combat View Post

 

Okay, obviously it would still work some added logic with having three different tables and so on. I mean, all roads lead to Rome, and this is mostly true in computer science as well. But it certainly isn't a secure way of doing things, to have a person duplicated and then the first copy of it deleted. I just wish that in 10 years, someone isn't going to have these kinds of rants about software and systems that I develop. biggrin.gif

 

Sounds like a predecessor had to build a relational database out of somebody else's over-leveraged Excel macros. It's never fun cleaning up other people's work, is it? 

post #6674 of 21761
Quote:
Originally Posted by warrenpchi View Post

Wait, I'm still trying to wrap my head around why someone would even want to do the above?  Things don't code themselves right?  So at some point in time, some bloke was attempting to accomplish something, and I can't figure out what that might be given the method used.
I may have been a bit too fast with my text. The context is respondents: they have personal information, such as addresses, phone numbers, and so on. These respondents can either respond "yes" or "no" to be in a certain study. There is a certain point in keeping them in a register no matter whether they wish to participate or not, for instance for the sake of not having to ask them twice, or more. Now, these respondents, that will participate, can:

A) have said yes, but have yet to actually sign papers on participation and have yet to answer the survey

B) have said yes and signed the papers, but have yet to actually answer the survey

C) have said yes, signed the papers but have an incomplete survey, as in having only partially participated

D) signed, participated, answered everything

Those who haven't done it all, will need reminders and the system creates reports each week for who remind and so on. This bloke created a myriad of different tables to keep these respondents in and moves them around from table to table depending on a, b, c or d.

I hope I made it easier to visualize lol.
post #6675 of 21761
Quote:
Originally Posted by Kamakahah View Post

Had to catch up on 10 pages so I'm late to the fried chicken convo but are there not any Southern Californians here?
Roscoe's Chicken & Waffles.
Mind blowing deliciousness. And you can get it with purple or red to drink. Doesn't get much better.

 

Customer of several years @ Sunset Blvd & N.Gower St...Hollywood, baby! 90% of the time at this location, 10% of the time @ W.Pico Blvd & S.La Brea Ave. President Obama last visited the Pico stop.

 

 789900

 

@ warrenpchi

 

Fittingly, when I gave up eating meat, my last chick was at Roscoe's!

New Posts  All Forums:Forum Nav:
  Return Home
This thread is locked  
Head-Fi.org › Forums › Misc.-Category Forums › Members' Lounge (General Discussion) › The diary entries of a little girl in her 30s! ~ Part 2