I've done this 
although the files are long gone:
Welcome to the (virtual) listening room.
The following are notes that I made at the time. Enter your own values here.
although the files are long gone:Welcome to the (virtual) listening room.
The following are notes that I made at the time. Enter your own values here.
Code:
Settings for importing and exporting .wav files into LTspice.
1/Set the voltage input source by holding down CTRL and right clicking the source.
2/In the 'Value' field enter:
wavefile=nameoffile.wav
----------------------------------------------------------------------------------------------
To export a file first label the node of interest, for example, Vout_loadL
Now add a spice directive including the quotes. For example:
.wave "C:\users\Karl\Documents\Working Files\leftout.wav" 16 44.1k V(Vout_loadL)
----------------------------------------------------------------------------------------------
NOTE...
In creating stereo files (split to mono) in Audacity something odd happens. The right channel .wav file, while perfect in media player, will not function in LTspice. The final output from the circuit under test is just silence.
To correct this, first split the tracks and export the left file as normal. Now undo (use edit>undo) and now reverse the tracks. Again export the left channel (which is now the right of course). That seemed to work.
You don't want to get integration errors by shaping a sine sweep with a Laplace element or RC circuit in LTspice.
It would be better to generate the sweep directly with an equation. I was working out how to do this, but got stalled by what seems to be a bug.
I'm sure I saw RIAA filters in Audacity once. If you can find it you could generate a sine sweep and then apply an inverse RIAA filter to it.
It would be better to generate the sweep directly with an equation. I was working out how to do this, but got stalled by what seems to be a bug.
I'm sure I saw RIAA filters in Audacity once. If you can find it you could generate a sine sweep and then apply an inverse RIAA filter to it.
I have a very accurated anti riaa generated .wav freq sweep from 20 Hz to 20Khz in 18 sec. Sent me a pm with if you want it.
Also included is a .asc file where you can uses wav files as input, thereby generating an anti riaa file as output on your desktop in 24/192.
Hans
In the .asc file attached to the above posting, there is a short circuit between in&output at voltage source E1. This interconnection should not be there of course. E1 is there to give control over the amplitude of the output voltage.
But much more important, I played a bit with this model and found to my big surprise that it works perfectly in LTspice IV, but not at all in LTspice XVII !! That is, importing .wav files goes as expected, but exporting .wav files is a mess.
Hans
But much more important, I played a bit with this model and found to my big surprise that it works perfectly in LTspice IV, but not at all in LTspice XVII !! That is, importing .wav files goes as expected, but exporting .wav files is a mess.
Hans
I'm using LTspice since the day it came out, late '90ies. Currently I'm still on version IV ... never change a running system, especially for mission-critical work.
I've tried VII several times and was underwhelmed each time, I think they really screwed it up. At some point I will have to migrate to VII, though.
Maybe I'm just to old and stupid to get it, but how does one use multiple simulation commands with VII efficiently? This is a core functionality for me.
In IV, it was straight-forward, set up your parameters for, say .AC and .TRAN, then simply switch between them by right-cklicking an empty area, select "edit simulation cmd", change to the tab you want, press enter, done. The selected sim command gets its "."-prefix while the other(s) are commented out.
Not so with VII, the problem is that the pre-defined fields don't switch to the proper content when switching tabs in the sim command editor! That is, when you switch from .AC to .TRAN the editor just studiply replaces ".AC" with ".TRAN" text while leaving all the parameters as they are instead of loading them from the original statement.
This of course ***** up everything, the sim statements get destroyed and you end up with errors just by selecting an other sim tab and pressing enter. What the hell were they thinking?
Of course there's a workaround by manually locating and activating / commenting-out the individual sim statements but this is as annoying as it ever gets.
Another PITA moment is that they dropped the direct editing of multi-line statements (multiple .param for example) and replaced it by a stupid "editor" that corrupts multi-line statements in that it only loads the first line. If you press enter the other lines are lost even if you don't change anything, and if you press ESC you finally get access to the true content and can edit here the other lines. To abort the editing, you need to press ESC twice. Again, something that doesn't make any sense at all, they just ****** it up!
I've tried VII several times and was underwhelmed each time, I think they really screwed it up. At some point I will have to migrate to VII, though.
Maybe I'm just to old and stupid to get it, but how does one use multiple simulation commands with VII efficiently? This is a core functionality for me.
In IV, it was straight-forward, set up your parameters for, say .AC and .TRAN, then simply switch between them by right-cklicking an empty area, select "edit simulation cmd", change to the tab you want, press enter, done. The selected sim command gets its "."-prefix while the other(s) are commented out.
Not so with VII, the problem is that the pre-defined fields don't switch to the proper content when switching tabs in the sim command editor! That is, when you switch from .AC to .TRAN the editor just studiply replaces ".AC" with ".TRAN" text while leaving all the parameters as they are instead of loading them from the original statement.
This of course ***** up everything, the sim statements get destroyed and you end up with errors just by selecting an other sim tab and pressing enter. What the hell were they thinking?
Of course there's a workaround by manually locating and activating / commenting-out the individual sim statements but this is as annoying as it ever gets.
Another PITA moment is that they dropped the direct editing of multi-line statements (multiple .param for example) and replaced it by a stupid "editor" that corrupts multi-line statements in that it only loads the first line. If you press enter the other lines are lost even if you don't change anything, and if you press ESC you finally get access to the true content and can edit here the other lines. To abort the editing, you need to press ESC twice. Again, something that doesn't make any sense at all, they just ****** it up!
Last edited:
Hi Mooly,
I tried all usual frequencies with LTspice XVII in between 44.1K and 384K.
As long as the word length is 16 bits, everything is fine.
But from 17 bits up to 24 bits, you will only get rubbish in the generated .wav file.
See image below, that is even relatively recognisable, but the outcome may be much worse.
Importing .wav files up to 24/384K no problem at all.
So we have a wave export bug in LTspice XVII.
And again, LTspice IV works without any problem importing and exporting with all word lengths and sample frequencies.
Hans
Attachments
And I have two programs installed on two machines. At one time I had a third version of the SWcad3, which built the stabilizer circuit according to your requirements. New models are suitable for LTspiceIV. You can use my collection:
LTspiceXVII_2019Jan29.zip — Yandex.Disk
LTspiceXVII_2019Jan29.zip — Yandex.Disk
Thanks Hans
Part of the problem for me is that I just don't use these features often enough to fully get to grips with them. Each time its an adventure to get it to work and this is one reason I make notes along the way... because I'll have forgotten next time.
I made the switch to LTXVII and now don't have LTIV installed at all.
Mike Engelhardt is pretty approachable over sorting bugs although I'm not sure how easy this one would be to fix.
The behavior seems to be turned off if there is a .subckt in the commands, but I haven't experimented with this yet.
I can edit multi-line statements if I use ctrl+Rclick, but it is certainly quite annoying that I have to do this all the time.
If I were you I would send a report to the email address in the Help->about window. But be specific, give him clear test cases that show exactly what the problem is. Programmers love you if you minimize the work they have to do to figure out what is wrong and what you want.
Personally I like to use multi-line statements like this:
.param
+ A=1
+ B=2
+ C=3
The + is standard SPICE syntax for a new line, and it is more compact and readable than
.param A=1
.param B=2
.param C=3
Especially when the parameters are long equations. But in the new LTspice it is much harder to use them this way.
If we are expected to figure out the new workflow and love it, then there should at least be a demonstration video which shows what the new workflow is and how it is supposed to work.
Ah, thanks for that, I forgot this shortcut. Helps with multi-line stuff, for me it's convenient enough to be a non-issue this way.
But the main problem is the switching between sim commands (I typically have .op, .ac, .tran and .noise all set up). I mean, how do you guys actually handle that in XVII?
The behavior I mentioned, I don't think it is a bug as this is the most elementary command, after all. They would have noticed, XVII is around for a while now. So I think it must be operator error...
However, as long as IV keeps running both unter native windows and wine I'll stick to that anway, also because it is very portable.
Mike has said that the preferred way is to ctrl+Rclick and change the old simulation command to a comment, then add the new command with the simulation directive window or clicking the Run button.
Then you can switch between them with ctrl+Rclick and uncomment. I still don't understand why he thinks this is easier.
Then you can switch between them with ctrl+Rclick and uncomment. I still don't understand why he thinks this is easier.