Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 9 months ago.
Improve this question
I want to acquire pressure data from a pressure sensor. When I write the data using the "write to measurement file", only one part of the data is saved and others are missed.
I also try exporting data to excel from the waveform chart. But I receive a message that says there is not enough memory.
What should I do to save whole the data without missing them?
Is there any way to save the data directly to the Hard drive?
Thanks
I don't like the expressVIs myself. Recording directly to a TDMS file is the way to go. There are great examples of writing to a tdms file in the Labview examples. I think the TDMS API is pretty intuitive as well, look at the TDMS palette under the File IO palette, all you really need for this is to open, write, then close.
TDMS are incredibly fast for writing to and allow multiple groupings and metadata at multiple levels. I use TDMS all the time in my applications and never miss any data.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been using vim for a few years and I love how easy it is to do simple tasks like insert above current line, delete whole line, etc. I've even mapped my caps lock to escape because of it!
One problem with vim that I could never get over was how much thinking navigation requires compared to mouse movements, even after you've learned the keys. I know about some of the movements like %, ^, $, f/F, t/T and using numbers before a command but I feel like it takes a lot more effort to use them and they disrupt my workflow.
For example, I need to delete the "/many/sections/" of this url and the cursor is in the middle of the word "really":
http://this/is/a/real|ly/long/url/with/many/sections/
With a mouse, it takes no thinking power to just click and select the sections I want to remove and hit delete.
If I do this in vim, I find myself thinking: Ok, first $ brings the cursor to the end. Then I want to delete those sections so I can use the '/' as deliminator and now I have to count how many of the '/' I want to move back. It's two and I have to search backwards so it's F, not f. So I think the command should be $d2F/.
Alternatively, I could have used 'm' as a landmark for the cursor and delete to the end from there but then I'd have to scan the url to look for letters to use. And if there was another m, I'd also have to press ; repeatedly or start counting.
This seems a lot harder than just using a mouse, even with the delay of moving my hands off the keyboard. This is especially true for multiple line selections where I find myself spending a lot of time counting words or lines or looking for deliminators.
Also, sometimes the command either deletes or doesn't delete some extra deliminator characters because I used f instead of t or vice versa whereas with a mouse, I can pinpoint exactly what I'm trying to select.
The / key is your friend. From where you are hit /ma ENTER. Then, hit D to delete the rest of the line.
The /maEnterD is probably the quickest solution and does not require hard motion planning. (And similarly use ? for reverse motion).
But if you feel you need more motion, you should definitely check Easymotion plugin. it expands the f,F motion to the whole window, rather than the single line.
Actually, I do agree that using F is quite cumbersome, I'd rather use text object, like vi) or dip.
Use gvim so you can use your mouse.
If you don't like planning, what about repeating?
$dF/.
doesn't require any thinking whatsoever.
wwwwwwwD
doesn't require any thinking either.
Anyway, I would do /ma<CR>D like already mentioned.
And nothing prevents you from using the mouse if you are more comfortable with it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to create a software that can convert readable-texts(non-English) to Audio sound output.
After some searches what I have realized that most of the existing audio readers are too robotic and lacks the human-speech like effects.
I am looking for some algorithm/paper-work, which can give me some idea on how to proceed/implement such a thing.
or
Does anyone know, How some of the world's best Text-Reader software works?
My expectation are:
Reduced Robotic-like sound, and more of Human-like sound
High Quality Output
Light weight, yet Fast process speed
**Please edit this question, if anyone thinks some points are missing on this aspect.
Some small steps might help you give some basic Idea of what happens-
You need to create a dictionary of words, each word with its name and sound.
Create your own signal processor, this will help you add effects to your sound, like you might want robotic, or a female version or something else.
Parse the text file you want to read in array formats, dividing each word and punctuations, to form an array and. eg. "I want to die, this isn't a correct way to live." this will form an array as {I:want:to:die:,:this:isn't:a:correct:way:to:live:.}
Use the punctuation to implement life like parameters like , for small pause and . for longer pauses in your audio reader.
Use the words to take out audio from your database(dictionary) list in point 1.
Play the whole array continuously with a pause between each array element, will work similar to spaces
I think these are major ways to do this. To make it faster you can use advanced sound processing tools, to cache small sound data and add data on fly while you are modulating sound signals.
Might this help you.
Could be nice if you can tell us what kind of app you'll create (Movil, Web, Desktop) and also in what code you'll develop it (Php, Java, C++, etc). Because if you search in google, you'll find a lot plugins for website that convert text to audio that you can download them and see the code.
Also it's hard to find an app that not sound like a robot and if you find it maybe you'll pay for it.
The "robotic" aspect of text to speech that you are concerned about is a matter of the quality of "prosody". This is an active research area. You could probably get a PhD for working on improving prosody in TTS systems. If you would like to read about current research you can try searching for "improving prosody in text to speech".
A big part of the problem is having an accurate model of speech prosody in a given language. The thesis "MeLos: Analysis and Modelling of Speech Prosody and Speaking Style" by Nicolas Obin (2012) contains a survey of the state of the art in speech prosody modelling. Or try searching for "text to speech prosody survey state of the art".
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
let's consider a variation of the "WAV to MIDI" conversion problem. I'm aware of the complexity of such a problem and I know that a vast literature about the more general Music Information Retrieval (MIR) subject exists.
But let's suppose here that we already have both the WAV and the MIDI representation of a music piece, so we actually don't have to discover pitches inside the WAV signal from scatch... we "just" have to match the pitches detected (using a suitable algorithm) with the NoteOn events contained in the MIDI representation. I definitely suppose we should use the information contained in the MIDI file to give some hints to the pitch detection algorithm.
Such a matching tool could be very useful, for example for MIDI "humanization": we could make the MIDI representation more expressive using the information retrieved from the WAV signal to "fine tune" note onsets, durations, dynamics, etc...
Does anybody know if such a problem has already been addressed in literature?
Any form of contribution or assistance will be greatly appreciated.
Thanks in advance.
At the 2010 Music Hackday in London some people used the MATCH Vamp plugin to align score to Youtube videos. It was very impressive! Maybe their source code could be of use. I don't know how well MATCH works on audio generated from MIDI files, but that could be worth a try. Here's a link: http://wiki.musichackday.org/index.php?title=Auto_Score_Tubing
This guy appears to have done something similar: http://www.musanim.com/wavalign/ His results are definitely interesting.
This seems like an interesting idea. What are you trying to do, is it just match the notes pitch? Or do you have something else in mind?
One possible thing that you could look into is if you know the note (as an integer value I think its been a while) that will be used to pass into the noteOn method, you may be able to do something with that to map it with a wav signal. IT depends on what you are trying to do.
Also, there are some things that you could also play around with in (I think it is called) the midi controller. Such as: modulation, pitch, volume, pan, or play a couple of notes simultaneously. What you could do with this though, is have a background thread that can change some of those effects as the note is being played. For example, you could have a note get quieter the longer it is played, or have a note that with pan between the left and right speakers, etc
I havnt really played with this code in a long time, but there are some examples of using a midi controller.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
When you write something in BASIC, you are required to use line numbers. Like:
10 PRINT "HOME"
20 PRINT "SWEET"
30 GOTO 10
But I wonder: who came up with the idea to use line numbers at all? It is such a nuisance, and left quite an "echo" in the developing (pun intended) world!
The idea back then was that you could easily add code everywhere in your program by using the appropriate line number. That's why everybody uses line numbers 10, 20, 30.. so there is room left:
10 PRINT "HOME"
20 PRINT "SWEET"
30 GOTO 10
25 PRINT "HOME"
On the first interfaces BASIC was available for, there was no shiny editor, not even something like vi or emacs (or DOS edit, heh). You could only print out your program on the console and then you would add new lines or replace them, by giving the appropriate line number first. You could not navigate through the "file" (the program was kept in memory, although you could save a copy on disk) with the cursor like you are used to nowadays.
Therefore the line numbers weren't only needed as labels for the infamous GOTO, but indeed needed to tell the interpreter at what position in the program flow you are editing.
It has a loong-loong history.
Line numbering actually comes from Dartmouth BASIC, which was the original version of the BASIC programming language and was the integral part of a so called Dartmouth Time Sharing System. That DTSS had a rudimentary IDE, which was nothing more than an interactive command line.
So every line typed inside this "IDE", and beginning with a line number, was added to the program, replacing any previously stored line with the same number; anything else was assumed to be a DTSS command and immediately executed.
Before there was such a thing as a VDT (video display terminal), we old-timers programmed on punch cards. Punch cards reserved columns 72-80 for sequence numbers - if you dropped your card deck and they all got out of order, you could put the deck in a card sorter that would order the cards based on those sequence numbers. In many ways, the BASIC line numbers were similar to those sequence numbers.
Another advantage in the BASIC world is that in the old days BASIC was interpreted as it was run. Using labels rather than sequential line numbers for branches would require a first pass to pick up all the labels and their locations, where as if you use line numbers the interpreter knows whether it needs to start scanning forwards or backwards for the destination.
Back in the day you didn't have a 2 dimensional editor like emacs or vi. All you had was the command line.
Your program was stored in memory and you would type in single line commands to edit single lines.
If you were a Unix god you could do it with ed or something, but for BASIC on a C-64, VIC-20, or TRS-80 you'd just overwrite the line.
So a session might look like:
$10 PRINT "Hellow World"
$20 GOTO 10
$10 PRINT "Hello World"
And now the program would work correctly.
Some older mainframes even had line terminals without a screen. Your whole session was printed on paper in ink!
The "Who?" would be the inventors, Kemeney and Kurtz.
After reading the replies, I checked the Wikipedia entry for "Dartmouth BASIC", and was surprised to learn
The first compiler was produced before the time-sharing system was ready. Known as CardBASIC, it was intended for the standard card-reader based batch processing system.
So, it looks like Paul Tomblin "gets the square".
Paul Tomblin's answer is the most comprehensive, but I'm surprised no one has mentioned that a big part of the BASIC project's initial goal was to provide a beginner-friendly interactive environment using timesharing. (Kurtz and Kemeny's vision for "universal access for all students" was far ahead of its time in this regard.)
The BASIC system that was developed to fulfill this goal featured Teletype ASR-33 (and later other) printing terminals. When connected to a timesharing-capable OS, these allowed editing and running BASIC programs in an interactive mode (unlike working with punched cards), but they are not cursor-addressable. Line numbers were a beginner-friendly way to both specify the order of program statements and allow unambiguous editing in the absence of a screen editor. The Wikipedia entry for "line editor" explains further, and anyone who's ever tried to use a line editor (such as the Un*x 'ed') can appreciate why Kurtz and Kemeny should be thanked for sparing the beginner having to learn the cryptic command sequences required for editing text in this manner.
They originated in FORTRAN, from which BASIC was derived. However, in FORTRAN only lines referenced by other lines (like GOTO targets) needed numbers. In BASIC they had a secondary use, which was to allow editing of specific lines.
Back in the fifties, when high programming languages were in their early beginnings, there were no terminals, no editors, no monitors (yes, no monitors), just card punchers and readers (for writing and reading the contents of cards into memory of a computer) and printers (for printing results, naturally).
Later, tape was introduced, but that's another story.
Each punch card had its own number. There were several reasons for that; from purely keeping them in order, to determining the sequence of execution. Each card was one line of code (in today's terms). Since, at that time, there were no constructs like if..then..else, or whatever variant of the like, the sequence of execution had to be determined somehow. So GOTO statements were introduced. They were the basis of loops. The term "spaghetti code" comes from that time period also, since badly written code was relatively hard to follow, like spaghetti on a plate :)
I'd guess it comes from assembler, where each instruction has an address which may be jumped to by another instruction.
Additionally, the first computers didn't have much memory, and storing a line number only takes two bytes (if done properly). Writing a label takes more memory, first in the location, where that label is defined, then in any jump command.
Finally in the good old days there weren't any fancy editors. The only "editor" was a simple command line interface, which treated everything starting with a number being part of a program and everything else as commands to be executed immediately. Most prominent example should be the Commodore 64.
Newer dialects of Basic don't have the need for line numbers any longer.
in Basic, if you didn't have a line number, how can you preform a
GOTO 10
that was a way to jump lines, a good way that was found ... more than 20 years ago!
today, the lines help us catching errors/exceptions because the debug engines are made to send us in the message that we got an exception on line xxx and we jump right away to it!
imagine a world without line numbers... how can a reporter be paid without the lines?
"Now that you know the novel, you have to write a summary with no more than 50 lines"
remember this? Even at the school we learn about line numbers!
if it wasn't invented, someone will already invented again so we could use it nicely :)
Not all versions of BASIC required line numbers. QBasic, for instance, supported labels. You could then jump to those with GOTO (ignoring Dijkstra's "Go To Statement Considered Harmful," for the moment).
The answer is already above. Paul Tomblin wrote it (with a caveat to zabzonk). Actually, I would argue that any answer which does not mention "punch cards" is incomplete, if it mentions neither punch cards nor FORTRAN, it is wrong. I can say that this is definitively right because my parents both used punch cards on a regular basis (they started with FORTRAN 66 and 77), then migrated to Basic and COBOL in the 80's.
In the early days, most programs were entered with punch cards. The punch cards were usually entered in sequence, usually one instruction per card, with labels (JMP/JSR targets) being a separate instruction card.
To edit your program, you replaced the card.
Later implementations added an optional sequence number on the right end of the line, so that when/if they got out of order, they could be resequenced by an automated reader.
Fortran used both numeric target labels on the left (col 1-5) and left a reserved block on the right (73-80) for sequence or comment.
When BASIC was initially written, it was decided to move the sequence numbers to the left, into FORTRAN's label field, and to allow overwriting prior cards' memory footprint... as an editing mode. This was intended for the interactive dev environment, but worked just as well with cards. And cards were used in some early implementations for a variety of reasons.
Keep in mind: Many computers were card-reader and printer interface right through the late 1970's. Even tho' interactive mode basics were available, card punched basic programs were frequently used. Since many simply were feeding into the IDE, they worked exactly the same way. Including needing a "Run" card at the end. In such cases, one could simply tack a correction card and another Run card to rerun with a variation on some variable; likewise, in complex programs, simply adding a corrected line of a card before the run was adequate to edit out problems without spending precious time finding the errant card itself.
I like the robot church on Futurama, on the walls were written stuff like
10 SIN
20 GOTO HELL
On the Speccy you couldn't edit a line without the line number.
I find them very helpful when pairing. I don't have to point at a line when my pair has the keyboard, I can just say, "on line 74, shouldn't that really be getMoreBeer()?"
The original editor for DOS was a wonderful utility called edlin. You could only edit a single line. To make life even more interesting in many versions of BASIC you could type lines out of order, line 10, 20, 30, 25, 5, The execution would be by line line number not by the order of appearance.